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Preface 



This volume contains the papers from the workshop “Radical Innovations of 
Software and Systems Engineering in the Future.” This workshop was the ninth 
in the series of Monterey Software Engineering workshops for formulating and 
advancing software engineering models and techniques, with the fundamental 
theme of increasing the practical impact of formal methods. 

During the last decade object orientation was the driving factor for new 
system solutions in many areas ranging from e-commerce to embedded systems. 
New modeling languages such as UML and new programming languages such 
as Java and CASE tools have considerably influenced the system development 
techniques of today and will remain key techniques for the near future. However, 
actual practice shows many deficiencies of these new approaches: 

— there is no proof and no evidence that software productivity has increased 
with the new methods; 

— UML has no clean scientific foundations, which inhibits the construction of 
powerful analysis and development tools; 

— support for mobile distributed system development is missing; 

— for many applications, object-oriented design is not suited to producing clean 
well-structured code, as many applications show. 

As a consequence there is an urgent need for discussing the role of object- 
orientation and new “post object-oriented” software engineering and program- 
ming techniques. The aims of the workshop, continuing the effort to bring to- 
gether pragmatic and foundational research in software engineering, were three- 
fold: 

~ to discuss the actual problems and shortcomings in software and systems en- 
gineering, to evaluate potential or partial solutions that have been proposed, 
and to analyze why some ideas were or were not successful; 

— to propose and discuss in a proactive way radically new innovations in soft- 
ware and systems engineering and to present visionary and explorative per- 
spectives and bold ideas for the modeling language, the programming lan- 
guage, the system development method, and the system development process 
of tomorrow; 

— to show how the wealth of past foundational research in software engineering 
can be uplifted to handle the new problems posed, among others, by the 
different levels of component and system granularity, the heterogeneity of 
components, the use of distribution and communication, and the request for 
appropriate human-interface support. 

The workshop program consisted of 36 invited talks by distinguished sci- 
entists and practitioners in the field. The participants were invited to submit 
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a written version of their talks for possible inclusion in these proceedings. All 
submissions underwent a careful refereeing process by the steering committee 
and the programme committee. This volume contains the final versions of the 
24 contributions that were accepted. 

Our sincere thanks go to all the referees who helped reviewing the submis- 
sions. 

We would like to thank David Hislop for his continuous support of the Mon- 
terey workshop series and in particular for helping us organize this workshop in 
Europe. The financial support of the US Army Research Office^, the US National 
Science Foundation, the Miinchener Universitatsgesellschaft, and the University 
of Venice is gratefully acknowledged. Marta Simeoni and several other mem- 
bers of the Computer Science Department of the University of Venice provided 
invaluable help throughout the preparation and organization of the workshop. 

Munich, November 2003 M. Wirsing, S. Balsamo, A. Knapp 



^ The views, opinions, and/or findings contained in this report are those of the au- 
thor(s) and should not be construed as an official Department of the Army position, 
policy, or decision, unless so designated by other documentation. 
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Architecture Specific Models: Software Design 
on Abstract Platforms* 

(The P2P Case) 



Egidio Astesiano, Maura Cerioli, and Gianna Reggio 

DISI, Universita di Genova, Italy 
{reggio , cerioli , astesjOdisi . unige . it 



Abstract. We address in general the problem of providing a method- 
ological and notational support for the development at the design level 
of applications based on the use of a middleware. In order to keep the 
engineering support at the appropriate level of abstraction, we formulate 
our proposal within the frame of Model Driven Architecture (MDA). 
We advocate the introduction of an intermediate abstraction level (be- 
tween PIM and the PSM), called ASM for Architecture Specific Model, 
which is particularly suited to abstract away the basic common architec- 
tural features of different platforms. In particular, we consider the mid- 
dlewares supporting a peer-to-peer architecture, because of the growing 
interest in mobile applications with nomadic users and the presence of 
many proposals of peer-to-peer middlewares. 



Introduction 

There are three sources of inspiration and motivation for the work presented in 
this paper. 

Engineering Support for Middleware based Software. The use of a middleware, 
encapsulating the implementation of low-level details and providing appropriate 
abstractions for handling them in a transparent way, improves and simplifies 
the development and maintenance of applications (see, e.g., [3]). But, the direct 
use of middleware products at the programming level without an appropriate 
software engineering support for the other development phases is dangerous. 
Hence, as it is argued in [6], the software engineering support, at the design level 
at least, has to take middleware explicitly into account, providing middleware- 
oriented design notations, methods and tools. The main aim of this paper is to 
show how well-established software engineering design techniques can be tailored 
to provide support for middleware-oriented design. 

Platform Independent versus Platform Specific Modeling. Relying on the fea- 
tures of a particular platform too early during the design phase results in rigid 
models that cannot be reused for further implementations based on different 

* Partially supported by Murst - Programma di Ricerca Scientifica di Rilevante Inter- 
esse Nazionale Sahara. 
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technologies. The so called MDA (for Model Driven Architecture), a technique 
proposed by the OMG, advocates the initial use of a Platform Independent Model 
(PIM) to be refined into one or more Platform Specific Models (PSM) that are 
its specializations taking into account the features of the particular technology 
adopted. The PSM will be adapted or even completely replaced accordingly to 
the frequent changes in the technology. However, in our opinion, the gap be- 
tween PIM and PSM can be too wide. Indeed, there are clearly architectural 
choices, like the level and paradigm of distribution, that are a step down to- 
ward the implementation, having fixed some of the details, but are still quite far 
away from a specific platform, because they can be realized by several different 
middlewares. Therefore, we advocate the introduction of an intermediate level, 
called ASM for Architecture Specific Model. Devising an ASM implies to define 
a basic abstract paradigm for the chosen architecture providing conceptual sup- 
port for the features of the different middlewares for that kind of architecture. 
Since our proposal is made in the context of the MDA and due to the relevance 
and success of development methodologies based on object-orientation in general 
and in particular supported by the UML notation, technically the ASM level is 
presented by a UML-profile. While many profiles have been proposed, few are 
middleware-oriented (the best known of them is the one for CORBA) and they 
are all supporting the PSM level, by providing a notation for the features of 
one particular middleware. We do not know of any UML-profile supporting the 
development of software based on P2P middlewares, and this provides further 
motivation to our work. 

Decentralization and Mobility. The use of mobile devices (mobile computing) 
supporting applications for nomadic users is becoming popular. That kind of 
application needs an appropriate underlying architecture. As it is easily un- 
derstood and explicitly advocated by many researchers (see, e.g., [2]), particular 
advantages seem to be provided by the so-called peer-to-peer (shortly P2P) archi- 
tecture, namely a network of autonomous computing entities, called peers, with 
equivalent capabilities and responsibilities. Recently many proposals have been 
put forward for P2P architectures, by researchers and companies, mainly under 
the form of P2P middlewares (see, e.g., [11,16,7,9,8,15]). We have been particu- 
larly stimulated by the proposal of PeerWare [4], that has been analyzed and used 
as a paradigmatic example within the project SALAD IN (http://saladin.dm. 
univaq.it/). Here, we present what can be considered an abstraction of most 
current proposals, that does not pretend to be the definitive choice, also because 
the P2P paradigm is very recent and our main aim is methodological in advocat- 
ing the MDA/ASM approach. 

Our notation supports the design of an application by a set of diagrams 
describing the system architecture, that is the peers and how they are grouped to 
share resources. Such peers and groups are typed and each such type is described 
by a diagram. In the case of a peer type, the diagram describes the activity 
and the resources used and provided by instances of that type, whereas for a 
group type it just describes the resources shared in such group. A most notable 
feature of our approach is that the middleware is naturally integrated into the 
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object-oriented paradigm, by describing it as an object, one for each peer, whose 
operations correspond to its primitives. The same pattern can be specialized 
to provide profiles for the PSM level, by specializing the classes representing 
the middleware objects and the resources and adding/removing features. As a 
consequence of the introduction of the ASM level, also the mapping of a PIM to 
a PSM is factorized in two steps, from PIM to ASM and from ASM to PIM. 

In this paper, in Sect. I, after presenting the basic ideas of MDA, we intro- 
duce a running example to illustrate the basic concepts and techniques. This is 
first done outlining the related PIM. In Sect. 2 we introduce our abstract P2P 
architecture paradigm showing informally how the example application can be 
mapped onto a P2P architecture. Then, in Sect. 3 we illustrate our profile by 
showing its structure and its use in defining an ASM for the example application. 
Finally, in the last section we draw some conclusions, discuss the relationships 
to existent work, and give some hints on future directions of research. 



1 Introducing and Illustrating MDA and PIM 

1.1 Model Driven Architecture (MDA) 

The Model Driven Architecture (MDA) proposed by OMG, see [10,14], defines 
an approach to system specification that separates the specification of system 
functionality from the specification of its implementation on a specific technology 
platform. Any MDA development project starts with the creation of a Platform 
Independent Model {PIM), expressed in UML. The PIM expresses only business 
functionality and behavior undistorted, as much as possible, by technology. Be- 
cause of its abstraction, it retains its full value over the years, requiring change 
only when business conditions mandate. Then, one or more Platform- Specific 
Models {PSM) are given, implementing the PIM. Ideally, the PSM are derived 
from the PIM by a mapping that converts the run-time characteristics and con- 
figuration information that we designed in the application model in a general 
way into the specific forms required by the target platform. Guided by standard 
mappings, automated tools may perform as much of these conversions as possi- 
ble. To simplify the definition of the mapping, the PSM should be expressed in 
UML, possibly enriched by linguistic tools to represent the platform ingredients. 
This is usually done by a UML profile (extension/ variant of the basic notation). 



1.2 A Worked PIM Example 

In this paper we will use as running example a P2P development of an application 
for handling the orders of a manufacture company: ORDS. Such company stores 
the products in a number of warehouses, each one serving some locations denoted 
by their zips, handles automatically the orders, and, to send the invoices to the 
clients, uses special mail centers. The orders are collected by salesmen, who may 
also verify the status of old orders. The case study we present here is a simplified 
toy version, with a minimal amount of features to illustrate our points. 
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Our abstract design of the ORDS system (modeled by a PIM, named 
ORDS-PIM), presented in this section, has been made following a simple method 
developed by our group. Such method assumes that the designed system is built, 
besides by <Cdatatype:^ representing pure values, by objects of three kinds of 
classes and provides stereotypes to denote them: 

- <Cboundary^ taking care of the system interaction with the external world, 

- <Cexecutor^ performing the core activities of the system, 

- <Centity:^ storing persistent data (e.g., a database). 

The first two stereotypes specialize active classes, while <Centity^ specializes 
passive classes. 




Fig. 1. ORDS-PIM Static View 



The static view of the ORDS-PIM, in Fig. 1, shows that the designed system 
has some interfaces (^boundary^ classes) for interacting with the entities of its 
context: the salesmen, the warehouse workers, which refill the stocked products, 
and the mail centers, which receive the data to prepare the paper mails. The 
<Cexecutor^ class OrderManager models how the orders, collected by the sales- 
men, are automatically processed. The persistent data used by the system, as 
the order archive and the stocks stored in the warehouses, are modeled by the 
<Centity^ classes. The invariants on these classes, reported in the same picture, 
require that there exists a unique OrderArchive, and each stock contains at most 
one card for each product. 

The behaviours of the active classes (^boundary^ and ^executor^) purely 
consist in reacting to time deadlines or to signals received from outside; they 
can be given by trivial statecharts that can be found in [13], together with the 
definition of the operations. 

The method requires all the classes to be fully encapsulated, that is, their 
instances may be accessed only by calling their operations. Moreover, all the 
dependencies among classes due to an operation call, have to be made explicit 
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by an <Caccess^ association, whose stereotype is offered by the method as well. 
Therefore, the <Caccess^ associations (visually presented by thick lines) fully 
depict the interactions among the system constituents. 

2 A P2P Paradigm 

At the moment no standard P2P paradigm seems to be established, not even 
in the practice. Not only several P2P-oriented middlewares have been pro- 
posed (see, e.g., [4,11,7,9,8], the Jxta Initiative (http://www.jxta.org/)), or 
the Bayou System (http://www2.parc.com/csl/projects/bayou/), based on 
different approaches, but several distributed applications have been developed 
directly implementing the P2P infrastructure for each of them (see [13] for a 
short list of some such systems). 

In the spirit of our proposal for the introduction of an Architecture Spe- 
cific level within the MDA approach, we present an abstract P2P paradigm 
for (mobile) distributed systems, trying to abstract as much as possible from 
those aspects that have different instantiations in the various proposals. Thus, 
a model based on the paradigm presented here is flexible enough to be imple- 
mented using different P2P middlewares and hence is not platform specific. For 
a more detailed discussion on the features of the proposed P2P paradigm and 
its relationship with existing P2P middlewares see [13]. 

2.1 P2P Paradigm Basic Concepts 

For us a P2P system is a network of autonomous computing entities, called peers, 
with equivalent capabilities and responsibilities, distributed each on a different 
host. Each peer may initiate a communication/cooperation and contributes to 
the activity of the system by offering resources, accessing the resources of the 
other peers, and performing private activities. Resource, here, is used in a broad 
sense and includes, for instance, (persistent) data, services, ports and sockets. 
Consequently “accessing a resource” may include making queries and updating 
data, calling a service, sending a message on a port, or publishing an event. 

In our paradigm, we assume that resources may be accessed both in a nomi- 
nated way, by their (physical or logical) address, or in a property oriented fashion 
as the result of a query operation for all the resources satisfying a given property. 
Moreover, to prevent unauthorized access to some resources we assume that the 
peers are parted in possibly overlapping groups, that create a secure domain for 
exchanging data, disregarding the actual realization of such boundaries. Then 
the resources of a peer are divided among the groups it belongs to, and the re- 
sources relative to a group will be accessible only to the members of that group. 
In other words, the local space of each peer is partitioned into a private and, 
for each group the peer is member of, a public part, that may be accessed by all 
and only the members of that group. The private part includes all the activity 
of the peer and is, hence, the only part where the actual access of the (public 
and external) resources takes place. The public parts offer the resources needed 
for the group collaboration. 
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Since we want to address the mobile case, peers are not required to be per- 
manently available to the groups of which they are members. Thus, while the 
membership of peers to groups is statically decided, their connection to a group 
dynamically changes. Each peer may decide to explicitly join or leave a group 
changing, as a side effect, the available resources of that group by adding or 
removing those resident on the peer itself. The capability of (joining) leaving a 
group is more flexible than simply (connecting to) disconnecting from a network, 
because it allows to selectively (share) hide the part of the peer resources public 
on that group. As the presence of peers on a group may dynamically change^, at 
any given time a peer connected to some group may access only those resources 
offered by the peers that are currently connected to such group. 

So far, we have discussed the P2P paradigm abstract features. Now, we add a 
somewhat orthogonal assumption, that the P2P paradigm be supported by some 
middleware, offering a common framework where coordination and cooperation 
of peers is supported, and the changing network topology is hidden. Then a 
peer will be a host where, besides the private and the public parts, a software 
component realizing the middleware services {middleware component) resides 
on. Such middleware component has the absolute control of the resources, that 
can be accessed only through the middleware primitives. There is just one basic 
access primitive for this level of middleware, from which other operations can be 
derived, by specializing some of its parameters. A call of such primitive, named 
perform, corresponds to selecting a community of resources and performing an 
action on each of them. Such community of resources is the union of the public 
communities for some group on a set of peers. Both the group and the set of 
peers are parameters of the call, as well as the action to be performed. 

The middleware is also the unique responsible for group management, in 
the sense that joining and leaving groups, finding the (currently connected) 
members of a group are services of the middleware, realized by the “middleware 
component” resident on the peer and offered to the (private part of the) peer. 



2.2 Mapping ORDS into the P2P Paradigm Architecture 

In this section we informally present how to translate the ORDS-PIM, defined 
in Sect. 1.2, into a distributed P2P system following the paradigm of Sect. 2.1. 
Then, that system will be designed using the UML profile of Sect. 3, getting the 
P2P oriented ASM for the ORDS case. 

To start, we need a rough description of the distributed structure of the sys- 
tem, that is which computers will be available, their users, and their connections 
to the network. In this case, we will also introduce some mobility aspects, to 
show how they are handled in the proposed approach. Let us assume that 

^ Following the approach in [1,9,5], we assume that the middleware masks unan- 
nounced disconnections, by mechanisms like caching and some reconciliation policy. 
That is, we regard the groups as realized on an everywhere available connection net, 
and trust the middleware to solve the problems due to this idealization. 
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— The company is structured in different branches. 

— Each salesman, branch, warehouse and mail center owns a computer. 

— The computers of the salesmen are portable and can be connected to Internet 
by means of a modem, while all the others are assumed to be workstations 
stably connected by Internet. 

The first step to derive a P2P model from the PIM is to devise the peers 
composing the system. In this case, obviously, we have a peer for each salesman, 
each warehouse, each branch, and each mail center. 

The next step requires to deploy the ORDS-PIM active objects on such peers. 
In this case the deployment of the <Cboundary^ objects (Salesman, MailCenter 
and WareHouse) is quite obvious, because their external users own a peer each. 
The OrderManager objects could be in principle be deployed on any host, as 
they interact equally with all the boundary elements. We decide to deploy an 
OrderManager on each branch peer, to exploit their computational capabilities. 

The groups allow to discipline the cooperation among the peers, which should 
cooperate only if some active objects deployed on them were already cooperat- 
ing within the ORDS-PIM, that is if there is an <Caccess^ association, between 
their classes (see Fig. 1). We have direct cooperations, when active objects ac- 
cess each other, like for instance OrderManager accessing MailCenter, or indirect 
cooperations when different active objects access the same passive object, like 
for instance Salesman and OrderManager sharing OrderArchive. Thus, in a first 
approximation, we can devise three groups for supporting the cooperations in 
Fig. 1: Mail (among branches and mail centers). Product (among branches and 
warehouses), and Company (among branches and salesmen). 

The objects of ^entity:^ classes that are accessed only by objects already 
deployed on a unique peer, will be deployed on the same, while those that are 
accessed by objects deployed on different peers need to be shared on some group. 
In principle, they could be deployed on any peer, but in order to minimize 
communications and to maximize availability, it may be more convenient to 
deploy them on one of the peers involved in the sharing. Thus in our example, 
the unique OrderArchive may be deployed either on the branches (together with 
the order managers) or on the salesman peers. Since the former are more stably 
connected and more powerful it seems sensible to use the branch peers to store 
the OrderArchive. Furthermore, we choose, as reasonable in a P2P setting, a 
distributed realization of the order archive, splitting it in several subarchives, one 
for each branch, that will contains the orders handled by the manager deployed 
on such peer. Analogously, the Stock objects could be deployed on the WareHouse 
or on the Branch peers. But, since each stock entity represents the status of the 
corresponding warehouse and may be accessed by several branches we deploy 
Stock objects on WareHouse peers. 

As a final step, all the calls of the operations of the objects that are now 
resources shared on some group, have to be converted into appropriate calls of 
the middleware services. 
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3 A Profile for Peer-to-Peer ASM 

In this section we will present, as a UML profile (see [12]), a visual object-oriented 
notation to model the P2P oriented ASMs following the paradigm illustrated in 
the previous section. 

Since we integrate our P2P paradigm within an object-oriented paradigm, 
it is most natural to consider, as resources to be shared, standard objects. Thus 
resources, being objects, hence naturally typed by their classes, are implicitly 
provided with a precise interface. Moreover, we may use the 00 typing mecha- 
nism at a higher level to classify the peers and groups constituting the system. 

There are two key points in our profile. First, we represent the middleware 
component on each peer as an object of a class predefined by the profile, offering 
as operations the middleware primitives. Thus, the access to its primitives is 
disciplined by the standard mechanism of operation call (see Sec. 3.4 and 3.5). 

Second, a model will consists of several UML (sub)models describing, re- 
spectively, the system architecture, the kinds of involved peers and groups. The 
P2P Static View describes the architecture of the system at the static level. It 
presents the types for the peers and groups building the system. The Architecture 
Diagram describes the actual instances of the peer and group types building 
the system and the memberships among them. The Resource Community Model 
describes the resources of the system shared on the groups of a type. The Peer 
Model describes the private part resident on the peers of a type, and which 
resources they offer and expect to find on each group they belong to. 

That splitting of the modeling into different views corresponds to a separation 
of concerns during the design phase, providing means for the specification of each 
part of the system in isolation, as far as possible, making explicit the assumptions 
on the outside world. Moreover, the consistency among these views provides 
a useful tool to check that the intuitions about the resources needed for the 
performance of some group activity meet the description of the same activity 
from the viewpoint of the involved partners. 

3.1 P2P Static View 

The P2P Static View presents the types of peers and groups used in the P2P 
system and for each peer type, the possible groups its instances belong to. 

In a P2P Static View only classes of the stereotype <Cpeer:^ or <Cgroup^, 
that are classes without attributes and operations, and associations of stereotype 
<Cmember:^ may be used. 

<Cmember^ are oriented associations going from a <Cpeer^ class, repre- 
sented by a box icon, into a <Cgroup:^ class, represented by an oval icon, where 
the multiplicity on the group end is always 1 (and hence it is omitted). In this 
way the association names allow to uniquely identify the groups a peer of this 
type belongs to. If there is only one anonymous association from a peer type 
into a group type, then it is implicitly named as the group type itself. 

As discussed in Sect. 2.2, the peers of our P2P realization of ORDS may be 
classified in four types: Salesman, Branch, MailCenter and WareHouse, while the 
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groups are of three types: Company, Product and Mail. In order to show a case 
where several instances of the same group type exist and different associations 
for the same peer types, let us decide that different groups of type Product 
represent a continent each. Each warehouse will serve (zip codes within) one 
continent and is, hence, connected to one Product group, while the branches need 
to be connected with all the groups of that type, in order to deal with orders for 
each locations. This classification will restrict the search space for a warehouse 
capable of handling an order. Such peer and group types are summarized below 




3.2 Architecture Diagram 

The Architecture Diagram describes the structure of the modeled P2P system 
by stating which are the peers and the groups building the system and the 
memberships among them. It is a collaboration at the instance level satisfying 
the following constraints. 

— The instances, represented as ClassifierRole, must belong to the types pre- 
sented in the P2P Static View (and are visually depicted using, as previously, 
the box and the oval icons) . 

~ The links, all belonging to the <C member^ associations present in the P2P 
Static View, are labeled with the corresponding association name. 

If the number of the peers and groups composing the system is not determined 
a priori, or they are too much to be shown on a diagram, we can attach to the 
object icons multiplicity indicators expressing the number of instances. 




The Architecture Diagram of the ORDS-P2P, above, shows that there is one 
group of type Company (Mail) connecting all peers of appropriate types, and 
three groups of type Product, and moreover that each warehouse is member of 
one of them while each branch is member of each such group. In this case, we 
have 4 branches, 98 mail centers, and any number of salesmen and warehouses. 

3.3 Resource Community Model 

A Resource Community Model describes the types of the resources shared by 
the members of any group of a given type. It simply consists of a UML package 
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named as the group type itself containing at least a class diagram, where the 
new special OCL basic types Peerld, Groupid and Resourceld may be used. These 
types corresponds to peer, group and resource identities to be used as arguments 
and results of the middleware primitives. They are used as a bridge among the 
different views composing a UML-P2P model. Since intuitively the resources are 
manipulated by the peer internal activity through the middleware, no calls of 
the middleware primitives are allowed within a resource community model. 

The models of the resource communities of the ORDS-P2P are presented 
below, and each of them consists of the shared data needed to realize indirect 
cooperations as discussed in the previous section. The details of the definition 
of each class are omitted, because they are as in the ORDS-PIM. 



Company 



OrderArchive 



Contains' 



Order 



Invoice 



Stock >1 Storecard 

Cards 



3.4 The Middleware 

We introduce the middleware in our profile by defining a UML interface, P2P MW, 
whose operations correspond to the services that it offers. Notice that the prim- 
itives provided by the (abstraction of the) middleware presented here are not 
intended to match directly any existing middleware. Indeed, we are aiming at a 
profile for the support of an intermediate level of design where the platform has 
yet to be decided, and only the architecture paradigm of the system has already 
been fixed. We may complement the P2PMW interface with a UML class real- 
izing it, say P2PMWclass, which will be then part of the profile definition. The 
UML description of the operations of P2PMWclass will give an abstract semantic 
description of the middleware primitives; whereas the attributes of P2PMWclass 
will give an abstract view of the information on the network managed by the 
middleware and on the current activities of the middleware itself. 

The middleware primitives use the special types Peerld, Groupid and Resour- 
celd, already introduced, and also RemoteAction, defining what can be done on a 
selected community of resources. RemoteAction is a specialization of UML action 
(Action is the corresponding meta-class), adding two new actions: 

— returnGopy that will make a deep copy of its argument in the private commu- 

nity of the calling peer and return its identity, 

— return Ref that will give back the identifier (element of the special type Resour- 

celd) of the argument. Such resource identifier, whenever used in a remote 
action in the correct resource community will identify the original resource. 

A remote action, as any UML action, allows to model both querying and imper- 
ative updating over a community of objects. To describe a query or an update 
on some particular resources in a community, we can use directly the identi- 
fiers of such resources, corresponding to a direct reference to the resources in a 
named style of middleware. But, it is as well possible to find them indirectly, for 
example by using an OCL expression of the form G.alllnstances->select(. . . ) for 
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selecting all resources of class C satisfying some condition, achieving in this way 
the anonymous style of resource lookup favoured by some middleware. 

A RemoteAction must be statically correct in the context of the communities 
on which it will operate; in particular no references to the caller environment 
may appear in it. That constraint on one side allows remote evaluation, and on 
the other bans interlinks between private and public communities (of different 
groups) and among the communities local to different peers, as the users cannot 
exploit (private) local object identities when assigning values to the attributes 
of (possibly remote) public objects through code execution. 

The primitives of P2P MW are: 

— mySelf();Peerld returns the identifier of the peer, where the middleware com- 

ponent is resident. 

~ join(Groupld) connects to the given group. 

~ leave(Groupld) disconnects from the given group. 

— isGonnected(Groupld):Boolean checks if there is an active connection to the 

given group. 

— wholsGonnected(Groupld);Set(Peerld)] returns the set of the identifiers of the 

peers currently connected to the given group. 

— members(Groupld,PeerType):Set(Peerld) given g and PT, returns the set of the 

identifiers of the peers of type PT that are members of g^. 

— perform(Groupld,Set(Peerld),RemoteAction):Set(OclAny) given g, ps, and ra, 

executes ra in all the public communities for group g of those peers in ps that 
are currently connected. Then, it collects the results of any returnGopy and 
return Ref actions, producing a, possibly empty, object collection and yields 
it as result. 



3.5 Peer Model 

A Peer Model describes the software required by the modeled P2P system on the 
peers of a given type. Hence, in a UML-P2P model there will be a Peer Model 
for each peer type present in the P2P Static View. 

A Peer Model for a peer type PT whose instances have the capability of being 
member of group of the types Gl, . . . , Gk consists of the following parts: 

— :P2PMW , a denotation of the used middleware component, that is a Classi- 
fier Role for the interface defined in Sect. 3.4, to recall that it is possible to 
use its operations in the private part. 

— for each group type GT in {Gl, . . . , Gk}: 

* a package GT- public defining the static structure of the public resource 
community made available to any group of type GT the peers of type PT 
belong to. 

* a package GT-external defining how the peers of type PT view the external 
resource communities provided by the other members of any group of 
type GT they belong to. 

^ Since memberships are statically fixed, the result of this operation is a constant, 
needed only to give the peers a linguistic means to access the group members. 
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Each of the two packages for GT defines a resource community by a class 
diagram that is a subset of the one of the GT Resource Community Model. If 
any of these two packages is empty (because the peers do no offer resources 
or do not require resources on such group), then it will be omitted in the 
diagram. 

— a package, named PT-private, that describes the part of the system resident 
on the peers of that type, parameterized by the references to the groups it is 
member of (determined by the <C member;^ associations in the P2P Static 
View). Such parameters are depicted over the lines connecting the packages 
corresponding to their types. 

A private part is any UML model, where the calls of the middleware object 
operations may appear, and that implicitly imports all the packages de- 
scribing the resource communities that the peer may access. There are some 
obvious static correctness requirements: a peer may only join/leave a group 
of which it is member; the calls to the primitive perform on some resource 
community has to be correct w.r.t. the “type” of the community itself. The 
type of its community and of the communities of different peers on a group 
of type GT is given by the two packages public and external for GT. 



Example: Branch Peer Model. Here we illustrate the use of the Peer Models 
on the example of the Branch peer type, shown below. The other Peer Models of 
(a slightly different version of) the ORDS-P2P example can be found in [13], as 
well as the full details of the Branch Peer Model, that we omit here for brevity. 



1 Product-external | 








1 Stock 1 



Company-local 



OrderArchive 



Branch-private | \/ Eu, As, Am V V 




OrderManager 




cancelOldOrders «auxiliary» 
invoices «auxiliary» 



In Sect. 2.2 we decided to deploy one object of the <C executor:^ class OrderMan- 
ager on each branch peer; thus we put the corresponding class in the private part 
of the Branch peer model. Moreover, we decided to realize the unique database 
of orders in a distributed way, deploying the orders managed by each branch on 
its peer. Thus, since the OrderArchive has to be shared with salesman, we will 
have its class in the Gom pa ny- public package. Analogously, as the branches need 
to access the warehouse catalogues, we will have the corresponding class Stock 
in the Product-external package. Notice that in the Branch Peer Model there is 
no information about the actual deployment of the Stock objects; it is simply 
assumed that they are provided by peers on the group Product. Thus, a change 
in the design of the actual location of those objects would not affect the design 
of this kind of peers. 

The OrderManager has to be slightly modified in order to accommodate the 
P2P realization and in particular the accesses to the shared data have to be 
mapped onto calls to the middleware primitives. Thus, for instance the PIM 
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version of the invoices method has to be modified by using the middleware to 
access the order archive, the stock and the mail. We leave as comments the PIM 
version of the shared resource access, to better show the difference. 

method invoices() 

{ os = perform (Com pa ny.mySelf, 

return Ref OrderArchive.alllnstances.pendingOrders()); 

\\ PIM version: os = archive. pendingOrders() 
for 0 in os do { 
z = 0.inv.zip; 
g = z.zip2area(); 
ss = perform(g,any, 

if Stock. alllnstances ->select(S.where->includes(z))<>{} 

thenjreturnRef mySelf};); 

\\ PIM version: ss = astocks->select(S.w/here- >includes(O.ZIP)); 
done = False; 

while(ss <> {} and not done) do 
{ done = perform(g,ss->first, 

Stock.alllnstances.takeQuant(0.prod,0. quant);); 

\\ PIM version: done = ss->first.takeQuant(0. prod, 0. quant); 

if done then { perform(Company,mySelf,OrderArchive. alllnstances. invoice(O));} 

else ss = ss - ss. first } } 

\\ PIM version: archive. invoice(O); 

\\ Moreover, in the PIM version it performed mail.toSend(O.inv); while 
\\ here we leave that responsibility to the mail centers; see comment below 

Notice that, since the warehouses are now classified by their area, we need to 
know how the ZIP codes are mapped onto the the group identifiers in order to 
perform a search on the correct group. This is realized by zip2area of the ZIP class 
with result type Groupid, that is, hence, added to the class. Notice that the OCL 
operation .alllnstances refers to those instances in the community determined by 
the enclosing call of perform, so for instance the first occurrence in the previous 
method refers to the public community for the group Company of the peer itself 
(if it is currently connected, otherwise it is empty) . 

A further difference in the definition of invoices in the distributed case is 
that we move the responsibility for calling the toSend operation is moved from 
the OrderManager to the MailCenter, that will periodically perform a query for 
invoiced orders, send the corresponding mail and update their status. 



3.6 Static Correctness of the Overall Model 

Besides the standard UML constraints on the static correctness, we impose some 
further conditions, following the principle that a strict typing helps the design 
of systems, by allowing an early, if rough, check of consistency. 

As the different parts of a model correspond to different views of the same 
system, besides the static correctness of each view, already stated before, we have 
to check for consistency among them. This has already been partially done. For 
instance, the form of each peer model depends on the P2P Static View and 
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the classes admissible in each public or external package of some group type 
GT have to appear in the Resource Community Model for GT. Now, we check 
the GT- public and GT-external packages for GT from all the Peer Models of the 
possible members one against the other in order to be sure that if a peer expects 
some resources from the community, some (other) peer is offering it on the 
same group. Hence, we require that for each group in the Architecture Diagram 
and each peer member of it, the GT-external package of the type of that peer 
is included in the union of the GT-public packages of the types of that group 
members. This condition does not guarantee that all the expected cooperations 
will really take place, as it is possible that the peers providing some resource are 
not connected at the same time as the peers needing such resource. But, this 
kind of failure is due to the dynamic configurations of the groups (to the actual 
presence of the members) and cannot be checked statically. 

4 Conclusions 

From the experience of some projects dealing with significant case studies, we 
have been impressed by the gap existing between the proposed rigorous tech- 
niques for software development from scratch and the use of the various kinds of 
middleware in the practice without any methodological support. In the context 
of the MDA {Model Driven Architecture), we have proposed the introduction of 
an intermediate level, between PIM and PSM, called ASM {Architecture Specific 
Model) and we have illustrated our proposal in the case of a P2P architecture 
where distribution and mobility are fully encapsulated by some middleware. The 
middleware is naturally integrated into the 00 paradigm of UML, describing 
its software components present on each host as objects whose operations corre- 
spond to its primitives. The idea of representing the middleware components as 
objects is general and powerful enough to be reused whenever designing a UML 
profile to model applications using some middleware. 

In order to complete the MDA picture, we need to define in the general case 
how to transform a PIM into an ASM presented by using UML-P2P. In this 
paper, we have just sketched how to handle the case of the ORDS application. 
The mapping will be given by a set of systematic guidelines. 

Moreover, to fill the MDA landscape towards the PSM for the special case of 
P2P architecture, we further need to define the notations to express the PSM, 
that are UML profiles for specific P2P middlewares, such as Peer Ware [4], Jxta 
[15], Xmiddle [9] et cetera, and guidelines to translate an ASM into the corre- 
sponding PIM. We can define such profiles following the way we have defined 
UML-P2P, just replacing the abstract generic ingredients with the more specific 
ones supported by that particular middleware. 
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Abstract. On the basis of some experience in the use of UML, we be- 
lieve and claim, contrary to a recent wave for allowing almost total free- 
dom as opposed to disciplined methods, that a tighter and more precise 
structuring of the artifacts for the different phases of the software devel- 
opment process may help speed-up the process, while obviously making 
easier the consistency checks among the various artifacts. To support 
our claim we have started to investigate an approach, that, though being 
compliant with the UML notation and a number of UML-based methods, 
departs from them both in the basic philosophy, that follows the “tight 
and precise” imperative, and in the technical solutions for structuring 
the various artifacts. 

Building on some previous work concerning the structure of the require- 
ment specification artifacts, here we complete upwards and improve our 
proposal, investigating the link between the analysis of the problem do- 
main and the requirement capture and specification. To that purpose 
we propose a rather new way of structuring the problem domain model 
and then the link with the system, that encompasses the most popu- 
lar current approaches to domain modelling. Then we exploit both the 
domain model and our frame for capturing and specifying the require- 
ments. From our construction we can derive rigorous guidelines for the 
specification tasks, in a workflow that allows and suggests iteration and 
incrementality, but in a way that is not just based on the single use cases 
and takes more care of the overall construction. The various concepts 
and constructions are illustrated with the help of a small case study. 



1 Introduction 

In recent years, we have seen the introduction and the acceptance of use-case 
driven approaches combined with object-oriented techniques, particularly in con- 
nection with visual notations such as UML [19]. This is the case of software 
development process models such as RUP (the Rational Unified Process [14]), 
Catalysis [6] and COMET [9]. In the last three years we have made some ex- 
periments in the use of UML-based and use case-driven techniques and of some 
related methods, both in teaching and by personal involvement. Those experi- 
ments were concerned especially with the early development phases, requirement 
capture and specification and then design. 

* Partially supported by the Italian National Project SAHARA (Architetture Software 
per infrastrutture di rete ad accesso eterogeneo). 
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Because of that experience, we have become increasingly convinced that, to 
be more effective in terms of both productivity and quality, those approaches 
need to be improved and complemented especially in two directions. The first is 
a tighter and more systematic structuring of the artifacts based on precise guide- 
lines for their building. The goal we want to achieve by that is twofold: first, cut 
experimentally endless discussions on the structural choices and thus making the 
process much faster; second, provide a better support to the consistency checks 
among the different artifacts. Indeed, it is well known that consistency is one of 
the hot problems in multiview modelling approaches [2] . Of course tight and pre- 
cise structuring is not enough for consistency checks, as long as we want (and we 
much need) to go beyond pure syntactic checks (see [7] also for references). Thus, 
there is a second sense of our “precise” qualification that does not refer to the 
structural aspects, but to the semantics of the single constructs. Indeed, another 
principle we follow is the use of constructs with an unambiguous well-defined 
semantics. Altogether, by the tight structuring and the use of semantically well- 
defined constructs, we here provide an example of what we call well-founded 
method, as a modern and more viable approach that still embodies the basic 
sound principles of the “explicitly formal” methods (see [5] for a perspective and 
a rationale of well-founded methods). 

In this paper, we continue the investigation and update the initial proposal 
first presented in [1] . In that paper, we have outlined some new ideas about the 
structure of the Requirement Specification artifacts. Here we complete upwards 
and improve that proposal, investigating the link between the analysis of the 
problem domain and the requirement capture and specification. Indeed one of 
our assumptions, backed by our own experience, is the neat separation between 
the problem domain and the system (as much advocated in the work of some 
pioneers, such as M. Jackson’s [10]). To that purpose, we propose a rather new 
way of structuring the problem domain model (RDM) and then the link with 
the system. Our proposal, centered on two views, the Conceptual View and the 
Work Case View, in a structural sense encompasses the two most popular cur- 
rent approaches to domain modelling, namely conceptual modelling and business 
modelling, and can be reduced as a specialization to each of those. Then we pro- 
pose a “system placement” activity, supported by a System Placement Diagram, 
to relate the system to the domain and, by that, to locate the system boundary. 

This paper is mainly aimed at presenting the structural aspects of our ap- 
proach; we present both its rationale and the technical aspects, illustrated with 
the help of a small running case study. However, the fact that we illustrate the 
structure with the end artifacts, should not induce to underestimate the rele- 
vance of the methodological aspects in the building of the artifacts. Indeed, in 
the development we make an ample use of iteration and feedback, as it is un- 
avoidable in any sensible method. But, also for lack of room, we only touch that 
issue, just providing some methodological guidelines for the workflow, while not 
presenting the various iterations we have followed when handling the case study. 

In the first section, we present the rationale and our way of structuring 
the problem domain. In the second, we outline the transition from the prob- 
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lem domain model to the requirement capture and specification, by exploiting 
our particular way of structuring the requirement artifacts. Then, after some 
methodological hints on the workflow, we discuss the relation to other and fu- 
ture work. Throughout the paper we illustrate our approach by means of a small 
case study, shown in Fig. 1. 



We have to develop a system AL_L to handle algebraic lotteries. Our lotteries are said 
“algebraic” since the tiekets are numbered by integer numbers, the winners are deter- 
mined by means of an order over such numbers, and a client buys a ticket by selecting 
its number. Whenever a elient buys a ticket, he gets the right to another free ticket, 
which will be given at some future time, fully depending on the lottery manager deci- 
sion. The number of a free ticket is generated by the set of the numbers of the already 
assigned tickets following some law. 

Thus, a lottery is characterized by an order over the integers determining the winners 
and a law for generating the numbers of the free tickets. To guarantee the clients of 
the fairness of the lottery, the order and the law, expressed rigorously with algebraic 
techniques, are registered by a lawyer before the start of any lottery. 

The system will be then realized as an on-line system, where the tickets must be bought 
and paid on-line using credit cards with the help of an external service. Possible elients 
must register with the lottery system to play; and elients access the system in a session- 
like way. An external service takes care of the authentication of the clients. 

Fig. 1. The AL_L case study 



2 Modelling the Problem Domain 

2.1 Method Rationale 

The distinction between the (problem) domain and the (solution) system has 
been recognized and accepted long time ago in the software engineering commu- 
nity (see, e.g., [10]). The problem domain consists of those aspects of the real 
world that are relevant for the system to be developed for providing a solution 
to the problem under consideration. For instance, in the case of a system for 
handling a lift the relevant domain aspects concern how the lift works, that is 
in which way the calls can be made, whether the cabin doors are opened/closed 
by the users, and the most typical habits of the users (e.g., a user immediately 
leaves the cabin once the doors are open). Of course, the separation line between 
domain and system depends on the way the problem is stated. For example for 
the algebraic lottery, the problem domain aspects concern how the clients buy 
the tickets, how and when the winners are drawn and so on. Instead, in our 
formulation of that problem, the way the tickets are sold to the clients (e.g., 
by using Internet and credit cards, by clerks using cash) is a choice to be made 
when devising the system and thus should appear in the requirements and not 
in the problem domain. 

More or less, any development method requires to model the problem domain 
either explicitly, by a specific task, or implicitly in the requirement specification 




Tight Structuring for Precise UML-Based Requirement Specifications 



19 



task. We prefer to separate the domain modelling from the requirement definition 
and to present the result in a specific document (the PDM), because, 

— that separation helps get a more abstract unbiased description of the system 
that we denote by System; 

— the resulting PDM may be reused for many different System, thus extending 
to the early phases of the development the MDA philosophy [12]. 

Currently, in the literature and also in the practice, there are two main ways 
to present a PDM: 

as a conceptual model: the PDM is a conceptual model of the entities present 
in the domain, in this case it is usually represented by a (UML) class diagram, 
where the classes correspond to such entities, the associations to their mutual 
relationships and, if allowed, the attributes to some characteristics of such 
entities. Sometime, some limited behavioural aspects are given by sequence/ 
collaboration diagrams. 

as a business model: the PDM is the description of a business, intended as 
an organized offer of functionalities (business use cases) to outside entities 
interacting with it (business actors), and with an internal structure (business 
object model based on business workers and business items). Clearly, in this 
case actors, workers and items correspond to entities present in the real 
world, and are not parts of the System to be developed. This technique has 
been introduced recently in the RUP development method [14]. 

In our opinion, the conceptual model approach is not satisfactory in the cases 
where the entities in the domain are highly interactive and autonomous (e.g., 
participants in a meeting), or the most relevant aspects of the domain are natu- 
rally presented as workflows (e.g., handling an order in an e-commerce system). 
The business model approach overcomes the above limits, and is quite satisfac- 
tory whenever it is possible to naturally determine the “business organization” ; 
however, it is problematic in the cases where the domain is static (e.g., the 
domain for a word processor concerning texts, paragraphs, documents, . . . ) or 
when, trying to find the “business organization”, we fix too early the boundaries 
of the System to be developed. Here we propose a somewhat more general tech- 
nique trying to avoid the negative aspects of both the above approaches, and 
such that both are particular subcases of our one. 



2.2 Problem Domain Model: A Proposal 

The structure of a PDM is shown in Fig. 2. We propose to model the various 
entities present in the domain by the Conceptual View, a UML class diagram, 
but where the classes may be also active, thus with a dynamic behaviour; even 
more we allow to model the autonomous features of their behaviour. Then, the 
most relevant cooperation among such entities may be modelled in the Work 
Case View part that consists of workflows of a special kind, named work cases. 
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Fig. 2. PDM Structure 



Conceptual View. The Conceptual View, a UML package containing at least a 
class diagram, makes explicit which are the entities appearing in the domain 
(they are modelled by objects whose classes appear in such package) and their 
mutual relationships, if any (modelled by associations among the corresponding 
classes). The other elements of the class diagram, such as attributes, operations 
and constraints, and the other diagrams in the package (as state charts defining 
the operations) may be used to model relevant aspects of such entities. In that 
package we may use the active class stereotype <Cauto» to indicate those domain 
entities capable of autonomous behaviour (i.e., they are not just reacting to 
external stimuli). An autonomous action of such entities is modelled by the self 
call of operations of the stereotype <A» (denoted by identifiers starting with a 
bold capital A). Below we show the Conceptual View of the AL_L case study. 



^How 
many free. 
tickets he 
may get. 



WinningOrder 


FreeTicketLaw 


iessThan(int,int): Booi 


newNumber(Set(int),int): int 




AbuyTicket(lnt) 
winnersDrawn 
newLotteryStarted | 
youHaveWon 



Lottery 




dim: Int 
running: Booi 






The number of tickets of 
the lottery is (2*dim)+1 . 



«auto» 

Manager 



AstartNewLottery(int,WinningOrder,FreeTicketLa\|; 
Adraw 

AgiveFreeTicktes(int) 



context C: Client inv: C.freeTickets >= 0 

context WO:WinningOrder inv: "x < y iff WO.IessThan(x,y)" is a total order 
context newNumber(asTks,J): 
pre: {-j, ■■■, +]} - asTks <>{} 

post: asTks->excludes( result) and -j <= result and result <= j 
context L: Lottery inv: 

All the tickets in L. tickets have different numbers and 

L.dim = 5000 * k with K >= 1 and L. tickets. num = {-L.dim ... L.dim} 

Lottery.alllnstances->size= 1 and Manager. alllnstances->size= 1 



The autonomous entities appearing in that domain are the clients, which may 
buy the tickets, and a manager, which starts the lotteries, draws the winners and 
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gives out free tickets. Because these activities are autonomous, we model them 
by means of four ^auto;^ operations; whereas we model other non- autonomous 
activities, such as to be informed of winning a prize, by plain operations (e.g., 
youhaveWon). In the domain there are also passive entities, describing the current 
lottery and its tickets. The constraints attached to the class diagram model 
relevant aspects of the domain entities (e.g., there is at most one running lottery, 
or the winning orders are total orders on the integer numbers). 



Work Case View. Technically, a work case is a variant of the UML collaboration, 
thus it allows to represent some cooperative effort among some entities present 
in the domain. As a collaboration, it has a name, precisely defines (the roles 
of) the participants, and may have some parameters. But we prefer to model 
the behaviour of a collaboration by means of an activity diagram expressing the 
causal relationships among actions made by the participants, instead of by a set 
of interactions (message exchanges). In this way we can just describe the causal/ 
temporal relationships among relevant actions made by the participants without 
necessarily presenting such actions as messages sent by someone to some other 
one. The reason of this choice is to keep the description of a work case quite 
abstract avoiding to introduce spurious objects (just to have someone calling 
some operations) or to make particular choices about who calls who. 

Notice that there is a clear difference between our work cases and the RUP 
business use cases. Indeed all the participants in a work case are modelled by 
the roles of the work case (recall it is a variant of a UML collaboration) , whereas 
in a business use case there exists a business organization, which is a special 
implicit participant interacting with all the other ones (business actors), and in 
general the latter do not interact each other. 

The description of a work case consists of three parts (see Fig. 2). The main 
part is a, possibly parameterized, UML collaboration, where its roles correspond 
to all the participants in the work case. Since we do not describe the work 
case behaviour by a collaboration diagram, we prefer to visually represent the 
corresponding collaboration in the following way: 




AECm 



where Name is the work case name; PI, . . . Pn are the parameters; AEl, . . . AEm, 
El, ...Ek are the roles (to be played by domain entities) of the participant in 
the work case; Cl, . . . Cn, AECl, . . .AECm, ECl, . . . ECk are classes appearing 
in the Conceptual View. We distinguish the class of the autonomous entities by 

using the icon Using the standard UML notation it should be represented 

by 
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Since we can attach to the collaboration icon a constraint, we can state, if any, 
which conditions the participants and the parameters of the work case have to 
satisfy. Then, a work case description contains a textual description made by 
using the natural language. It must start with a sentence of the form “When 
...” expressing under which conditions the considered domain entities may take 
part to the work case, and must consist of sentences where the subjects are 
autonomous participants and where the object complements are participants. 
The last part of a work case description is a visual presentation of its behaviour 
by means of a UML activity diagram. The action-states of such diagram can 
be only calls of the operations of the work case participants, and the conditions 
properties on the states of the work case participants. In Fig. 3 we present one 
work case of the AL_L RDM (the remaining ones: Buy Ticket, Draw Winners and 
Give Free Tickets can be found in [3]). This work case is quite simple; it just says 



,.,X 

Client 




textual When no lottery is running, the manager may start a new one giving the 
dimension of the lottery (a natural greater than 0 and multiple of 5000), the law for 
generatiug the numbers of the free tickets (a fuuction which given a set of integers finds 
a new number not belonging to it) and a total order on integers, which will be used to 
find the winners. 

All clients, will be informed of the new lottery. 

Then, a lottery is running and is characterized by the data given by the manager, and 
all its tickets are available. 



T 

( MAN.AstartNewLottery(D,WO,FTL) ) 



behaviour ( for all c in CLIENTS do c.newLotteryStartedQJ 



( L.startedLottery(D.WO,FTL)~) 




Fig. 3. AL_L RDM: Work Case Start New Lottery 
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under which conditions the manager my start a new lottery and what happens 
when he does that (the clients are informed, and the characteristics of the new 
lottery are recorded by the Lottery domain entity). 

To keep the presentations of the behaviour views of the work cases simple 
and quite readable, we strongly suggest defining appropriate additional opera- 
tions, similarly to those used in [19] for presenting the “well-formedness rules”. 
For example, in the work case Start New Lottery we have used the operation 
started Lottery to describe the update of the Lottery domain entity, 
context Lottery: :startedLottery(D: I nt, WO; WinningOrder,FTL:FreeTicketLaw) 
post; seif.running and seif.dim = D and 
seIf.winningOrderr = WO and self. FreeTicketLaw = FTL and 
seIf.availableTickets.num = { -D ... D} 

3 Capturing and Specifying Requirements 

3.1 System Placement 

Once we have given the RDM, the next step of the development of the System 
is “to place it” in the domain by making precise which problem it must solve. 
This task consists of the following activities: 

1. add a class for System to the class diagram in the Conceptual View; 

2. decide which entities of the domain will be encompassed in the System; that 
is, if they are autonomous their activities will be realized by the System, 
otherwise the data that they contain will be preserved by the System; place 
them inside the icon of the System class; 

3. decide which entities of the domain will interact with the System; connect 
them with the icon of the System class by a line; 

4. decide if the System needs to cooperate with further external entities (not 
present in the domain); usually they are devices or entities offering services 
to support the System activity; add them as new classes to the diagram and 
connect them with the icon of the System class by a line; 

5. decide which work cases the System will support (clearly all their participants 
have to be included in those considered at points 3 and 4; for each of them 
place the corresponding collaboration pictures over the class diagram. 

After having performed the above tasks, you have got what we call “System 
Placement Diagram”, where for simplicity we drop attributes, operations, and 
associatian multiplicities. 

Notice that placing the System includes of course the definition of its bound- 
ary, which is recognized to be an important task almost in any development 
method (see [17,11]). If we consider the AL_L case study, we can see how we can 
place different systems in the domain described by the PDM given in Sect. 2.2. 
For example: 

a) The System must completely automate the handling of the lottery using 
Internet, and taking advantage of an external authentication service and of 
a credit card service for the payments. 
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b) As for the previous case, but the System will not replace the manager de- 
ciding, e.g., when to draw the winners, and email will be used for some 
communications with the clients. 

c) The System just helps the clerks to sell the paper tickets to the clients by 
showing the available tickets, printing the tickets, generating the list of the 
winning tickets, and printing the free tickets, which will be given by the 
clerks to the clients that show a paid ticket. 



For what concerns the work cases all of them will be supported by the above 
systems. In this paper we consider case b), and below we show the resulting 
System Placement Diagram. This diagram will be the starting point to capture 
and specify the requirements. 




3.2 Overall Structure of a Requirement Specification 

In our approach, the Requirement Specification artifacts consist of different views 
of the System, plus a part. Data View, needed to give a rigorous description of 
such views. Its structure is shown in Fig. 4 by a UML class diagram. 

Context View describes the context of the System, that is which entities (con- 
text entities) and of which kinds may interact with the System, and in which 
way they can do that. Such entities are further classified into those taking ad- 
vantage of the System {service users), and into those cooperating to accomplish 
the System aims {service providers). That explicit splitting between the System 
and the context entities should help avoid confusions between what exists and 
needs just to be precisely described (context entities) and what instead has to be 
developed (System) on which we have to find (capture) the requirements The fur- 
ther splitting between users and providers should help distinguish which context 
entities cannot be modified by the developer (providers), and those which may 
be partly tuned by the developer (users), e.g., by fixing their interface towards 
the System. 

Use Case View, as it is now standard, shows the main ways to use the System 
{use cases), making clear which actors take parts in them. Such actors are just 
roles {generic instances) for some context entities depicted in the Context View. 

Internal View describes abstractly the internal structure of the System, which 
is essentially its Abstract State. It will help precisely describe the behaviour of 
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Fig. 4. Requirement Specification Structure 



the use cases, by allowing to express how they read and update it. UML allows 
a single use case to have a proper state, but we prefer to have a unique state for 
all the use cases, to help model their mutual relationships. 

Data View lists and makes precise all data appearing in the various views of 
the System to help guarantee the consistency of the concepts used in such views. 

Some of the above views (e.g.. Internal View and Context View) are new w.r.t. 
the current methods for the 00 UML-based specification of requirements. In our 
approach, they play a fundamental role to help ensure the consistency among 
the various use cases and of the whole specification. 

3.3 Examples from the AL_L Case Study 

Here we illustrate the proposed structuring for the requirement specification 
artifact, showing its use in the AL_L case study. Notice that here we present the 
result of an activity that includes various steps and iterations. For lack of room, 
here we do not discuss those aspects of incremental development with feedback. 
We just provide a hint in Fig. 5. 

Data View. The Data View for the AL_L case, see Fig. 6, is quite simple and 
just introduces three data types: the orders for finding the winners, the rules 
for finding the numbers of the tickets to be given freely, and the data needed to 
identify a credit card. 

Context View. The Context View of the AL_L System, shown in Fig. 7, consists 
of a class diagram, where there is a class AL_L of stereotype <cSystem» whose 

unique instance is the System, some classes of stereotype <SU» (icon whose 

instances are users of the services provided by the System (the clients and the 
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Fig. 5. Requirement Specification Tasks 



«datatype» 




«datatype» 




«datatype» 


WinningOrder 




FreeTicketLaw 




CreditCardData 


lessThan(lnt,lnt): Bool 




newNumber(Set(lnt),lnt): Int 




ok: Bool 



context WO: WinningOrder inv: “x < y iff 0.lessThan(x,y)" is a total order 
context newNumber(asTks,j): 
pre: {-j, +j} - asTks <> {} 

post: asTks->excludes(result) and -j <= result and result <= j 

Fig. 6. AL_L: Data View 



manager); and some classes of stereotype <SP» (icon \ \ ) whose instances 

are providers of services used by the System (the email, the credit card service 
and the authentication service). In this diagram we show the mutual interfaces 
among these classes, that is in which way they may interact, using the standard 
UML interface construct. In Fig. 7, for example, we can see that the interface 
ToEmail of the Email context entity is really simple, just offering the possibility 

I 

Q and 

visually present respectively that a class C realizes/uses an interface I. The in- 
terfaces appearing in this diagram are usually given apart (here in the bottom 
part of Fig. 7). 

The Context View may include also some information on the behaviour of 
the <SU» and <SP» classes, but not of the <System» class, to model the 
assumptions on the behaviour of their instances on which the System relies. 

Internal View. The Internal View describes at an extremely abstract level the 
structure (architecture) of the System. This structure consists of a unique active 



to receive request to send an email message. 



C <--0 
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CreditCard Handler 



CCReq 



areRegistered 

areAvailable{Set(lnt)) 

confirmTicket{int) 

connected 

connectionEnd 

error 

failedRegistration 






Authentication 



CCAnsw 
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AuthReq 



:x 



AuthAnsw 



«system» 
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ToEmail 



X' 

Client 



X 
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\ Email \ 



«interface» 

ToClient 
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«interface» 


ManaqerReq 




ToEmail 


draw 




send(String, String) 


give(lnt) 






startNewLottery(lnt, Order, Law) 





«interface» 

FromClient 



availableTickets? 
buyTicket(lnt) 
connectMe 
discon nectMe 

registerMe(String,CreditCardData) 



«interface» 

AuthReq 



register(Clientlnfo) 

check(Clientlnfo) 



«interface» 

CCReq 



check(CreditCardData) 

charge(CreditCardData,lnt) 



«interface» 

AuthAnsw 



ok(Clientlnfo) 

wrong(Clientlnfo) 



«interface» 

CCAnsw 



wrongCard(CreditCardData) 

okCard(CreditCardData) 

notCharged 

charged 



Fig. 7. AL_L Requirement Specification: Context View 




Fig. 8. AL_L Requirement Specification: Internal View 



object able to perform the System activities (abstract executor) and by many 
passive objects describing the System Abstract State. 

In Fig. 8 we show the Internal View of the AL_L case study. It consists in a 
class diagram containing exactly one class of the stereotype <cA_Executor», and 
several passive classes defining the parts of the System Abstract State. 

The instances of the class Clientinfo represent the information relative to the 
client context entities. Very frequently, the Abstract State must contain infor- 
mation about some context entities, and so we propose a standard way to treat 
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these cases We name CENTInfo the class of the information on the context enti- 
ties of class CENT, and assume that its instances are in bijective correspondence 
with those of CENT, and thus with the context entities. Furthermore, this corre- 
spondence is supported by an operation CENT::lnfo: CENTInfo that returns the 
information element corresponding to a context entity. op(P)). 

Following this approach, we avoid, on one side, models where the presence 
of a class named as a context entity class, say Client, requires to think about its 
true nature (e.g., is it a database relation ? or a kind of interface taking care 
of the interactions with such context entities” ? or . . . ), and, on the other one, 
precise but too much detailed models, where the association of the information 
to the corresponding context entities is realized, e.g., by using codes uniquely 
identifying the entities. 

The class diagram of the Internal View describes implicitly also the “Abstract 
State” of the System (technically the state of the ^System» class appearing in 
the Context View) in the following way: for each association in the diagram from 

the <CA_Executor^ class 
an attribute A: Bag(C). 



«A_Executor» 



A ^ 


Q 







the <cSystem» class has 



Use Case View. The Use Case View consists of a UML “Use Case Diagram” and 
of a Use Case Description for each use case appearing in it. But, for us the actors 
appearing in the Use Case diagram are possible roles for the entities outside the 
System interacting with it (context entities, defined in the Context View). Thus 
each actor will be denoted by a name, expressing the played role, and by a class, 
appearing in the Context View, showing which kind of context entities may play 
such role. Moreover, since the context entities are distinguished between users of 
services provided by the System and providers of services needed by the System 
also the actors will be distinguished in the same way. The same icons used for 

the context entity classes will be used for the actors ( 

The Use case Diagram for the AL_L case study is shown below. 



X and \ \ ) 






Tight Structuring for Precise UML-Based Requirement Specifications 



29 



textual When a client is not registered may register himself to the lottery system by 
giving his email and the data of a credit card. The system check the credit card data 
with the credit card service, if they are ok and are validated by the credit card service, 
then the system registers the client with the authentication service, informs him that 
he has been registered, and he will be registered; otherwise the system informs him 
that his registration has failed. 



behaviour 



registerMe(em,crCard) 
[ not crCard.okO ] / 
C.failedRegistrationQ 



registered->excludes(C) ] 



registerMe(em,crCard) 
1 crCard.okO ] / 
CC.check(crCard) 



okCard(crCard) / 
AH.register(C); 
register(C,em,orCard); 
areRegisteredQ 



AL_L 




interaction 



context AL_L::register(C:Client,em:String,crCard:CreditCardData) 
post: registered-> 

exists(CI — Cl. email = em and Cl.creditCard = crCard and C.Info = Cl) 



Fig. 9. AL_L Requirement Specification: Use Case Register 



Notice how the client context entities may play two different roles, when inter- 
acting with the System, as registered client (RC) when playing with the system, 
and as normal client (C), when trying to register. 

A Use Case Description, see those of two use cases of AL_L in Fig. 9 and 10 
(the remaining use case may be found in [3]), consists of a textual presentation 
and of one or more views, of different kinds, of the use case. 

The textual description should be expressed by sentences where the subject 
is either one of the actors or the System, and may start with a sentence of the 
form “When ...” expressing under which condition the use case may happen 
(pre-condition) . 

Any Use Case Description must include a Behaviour View, which is a state- 
chart for the <cSystem» class describing the complete behaviour of the System 
with respect to such use case. Such statechart, see, e.g., Fig. 9 and 10 has par- 
ticular features. The transition from the initial state should be labelled by the 
“pre-condition” , its events may be only call of the operations of the <cSystem^ 
interfaces, its conditions may test only the System Abstract State and the event 
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textual When no lottery is running, the manager may ask to the system to start 
a new one by giving its dimension (a natural greater than 1), winning order (an order 
on integers, which will be used to find the winners) and free ticket law (for generating 
the numbers of the free tickets, just a function which given a set of integers finds a new 
number not belonging to it). Then, a new lottery will be running having the dimension, 
winning order and free ticket law given by the manager. 

The system will inform all the registered clients by an email message that a new lottery 
is running. 



1 



behaviour 






[ not lottery.running ] 

) 



startNewLottery(D,ord,law) / 
for all c in registered do 
EM. send(c.email, “Start new lottery") 
startedLottery(D,WO,FTL); 



0 



causal 






not lottery.running ] 



( AL_L.startNewLottery(D,ord,law)) 






(for all c in registered d(EM.send(c. email, "Start new lottery");) 






( AL_L.startedLottery(D,WO,FTL): ) 



context AL_L::started Lottery (D:lnt,WO:WinningOrder,FTL:FreeTicketLaw) 
post: tickets = {}and lottery.dim = D and 

lottery.Order = ord and lottery.Law = law and lottery.running = True 



Fig. 10. AL_L Requirement Specification: Use Case Start New Lottery 



parameters, and its actions may only be calls of the the operations of the actors, 
as defined by their interfaces, or actions updating the System Abstract State. To 
keep the behaviour views simple and quite readable we use appropriate addi- 
tional operations, as previously suggested for the work cases. 

The behaviour view is a “complete” description of what the System does 
that concerns the use case. In Fig. 9 we can see that the registration of a client 
requires some collaboration by the credit card service and the authentication 
service, that affects the System Abstract State, and that the use case has three 
possible cases (all of them visually presented in the diagram); whereas in Fig. 10 
we see that the registered client will be informed by an email message of the new 
lottery, and that the use is really simple, not having any alternative way. 

A Use Case Description may include any number of Interaction View, which are 
sequence (or collaboration) diagrams representing the interactions happening in 
a scenario of the use case among the context entities and the System. The Use 
Case Description in Fig. 9 has an Interaction View, whereas the one in Fig. 10 
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none. Any Interaction View must be coherent with the Behaviour View (that is, 
it must represent a particular execution of the complete behaviour of System 
described by such view). 

We think that the Interaction View are really important showing visually 
who does what, but they are complementary to the Behaviour View because they 
cannot show under which conditions the various messages may be exchanged 
and their effects on the System Abstract State. E. 

A Use Case Description may include also a Causal View (see for example 
Fig. 10), which is an activity diagram describing all the relevant facts happening 
during the use case and their causal relationships. The relevant facts (technically 
represented by action-states of the activity diagram) can be only calls of the 
interface operations of System by the actors, calls of the operations of the actors 
by System, UML actions producing side effects on the System Abstract State. In 
addition, the Causal View must be coherent with the Behaviour View, in the sense 
that the causal relationships among “facts” that it depicts may happen in the 
behaviour depicted by the state chart. 

The various views listed above play different roles in the description of a use 
case and are partly complementary and partly overlapping. The choice of which 
of them to use depends on the nature of the considered use case. The only rule 
enforced by the method is that the behaviour view is mandatory, because it 
obliges to present all the behaviour of the use case (e.g., all possible alternative 
scenarios are included), even if it may be less readable than the others. However, 
due to the nature of the UML state chart, the behaviour view cannot be a 
complete description of the use case, indeed; it does not allow to express who is 
calling the operations to which System reacts. 

4 Related Work and Conclusions 

The approach that we have outlined (see [3] for an extended version with more 
complex case studies), here limited to the early development phases (see [4] for 
the design phase), is in the line of some of the best-known methods for software 
development, adopting a multiview and use case approach and using the UML 
notation. But it departs from them, at least to our knowledge, in some important 
respects, both from the methodological and the technical viewpoint. 

First, on the method side, the overall major goal is to propose a more sys- 
tematic and stringent approach, in the sense that the overall structure of our 
artifacts, both for the RDM and the Requirements, is constrained in order to 
tightly relate the components and have at hand the possibility of performing a 
number of consistency checks. This view contrasts with the almost total freedom 
given, for example in RUP [14], where the structure is just based on the use case 
descriptions. The same freedom, just use case diagrams and use case descrip- 
tions, is given for the Requirement Specification phase in COMET [9], in sharp 
contrast with the detailed structure and the many constrained guidelines and 
notations for Analysis and Design. That level of freedom is, on the other hand, 
explicitly advocated, for example in [8], on the basis that experience matters 
more than stringent structuring and rules. There the underlying philosophy is 
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admittedly the same of the Agile Methods Movement (see [18], for an interesting 
discussion and references) . However, while we do not deny that highly skilled and 
experienced software developers perhaps need only loose guidelines and a liberal 
supporting notation, from our experience we have seen that, for less experienced 
people, such liberality is a source of endless discussions, contrasting choices and 
a proliferation of inconsistencies. Moreover, we believe that our “tight and pre- 
cise” imperative and the related techniques may help from one side reduce the 
amount and the fuzzy verbosity of some documentation and on the other provide 
effective guidelines for passing to the design and then the implementation phase, 
though we have not yet explored all the later phases. 

The approach taken in Catalysis [6] , that in other details shows some similar 
general views to ours, is not directly comparable, being an overall transforma- 
tional approach based on components that are refined from business modelling 
to implementation units. Definitely our way of structuring requirements is not 
targeted to a transformational approach; we are more interested in providing a 
separate step preliminary to devise in a rather structurally independent man- 
ner, a model-driven software architecture of the system. Indeed, we have already 
performed some experiments to pass from a requirement specification in the 
suggested form to a design document, for which too we have proposed a more 
tight and precise structuring. Our approach is totally compliant with the OMG 
Model Driven Architecture philosophy [12] and it is within that framework that 
we intend to explore the connection with the implementation phase, passing from 
Platform Independent Models to Platform specific Models and then to code. A 
second more specific methodological difference is the strict and explicit separa- 
tion between the Problem Domain Model and the system, in the line for example 
of [10]. That distinction was and is somewhat blurred in some classical and Ob- 
ject Oriented approaches, though revisited with UML (see, e.g., [13,8] for very 
recent examples). In other approaches that distinction has been reintroduced 
and phrased in the distinction between Business Modelling (e.g., in [14]) and 
Requirements. 

On the more technical side there are a number of major distinctions with the 
extant work, namely 

— the RDM structure, encompassing conceptual modelling and business mod- 
elling; 

~ the System Placement activity, that encompasses the search for the system 
boundary; 

~ the use of the Context View to make explicit the distinction between the 
system and its environment and as a basis for defining the requirements 
about the interaction of the system with its context; 

— the explicit use of the concept (a class) of System, both in the context dia- 
gram and in the use case descriptions, where we specify the System behavior 
related to a specific use case with a statechart; 

— the use of a very Abstract State, instead of the many optional use case states, 
to allow expressing abstract requirements about the interaction of the System 
and the context, without providing an object-oriented structuring at a stage 
when such a structure is not required and can be premature. 
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Notice that the use of the class System is not in direct contrast with the tra- 
ditional object-oriented approaches, where the presence of such a class, at the 
level of analysis and design, is considered a typical naive student’s mistake. Still, 
because of the fact that those approaches also at the requirement level start 
with an object structure, the presence of that class is most unusual. However 
the danger of providing an object structure not immediately needed when defin- 
ing the system requirements has been remarked by many authors (notably M. 
Jackson, see, e.g., [10]). Even more interesting, also in Catalysis, that claims to 
be completely object-oriented, a class system and a context diagram is used in 
the preliminary phases and it appears in the sequence diagrams explaining the 
role of the system (see [6, p.l5, fig 1.16]). Of course the context diagram with 
the system initial bubble was the starting diagram in the Structured Analysis 
approach [20]. 

Finally we just mention that in our approach the choice and use of the UML 
constructs is guided by a careful semantic analysis (see, e.g., [15,16]), that has 
led us to prevent and discourage the indiscriminate use of some features that, 
especially in combination, may have undesirable side-effects, like interferences 
and ambiguities. 
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Abstract. We discuss the integration of performance modeling and 
analysis in the software development process. Various approaches have 
been recently defined to integrate performance models and specihcation 
languages and models to derive or validate non-functional properties of 
a software system. Such integration of quantitative performance anal- 
ysis should provide feedback easily understandable by the software de- 
signer and system developers. A framework that allows the combination 
of different performance modeling techniques and methods, dehned at 
different levels of abstraction, should better support performance analy- 
sis and validation of complex and heterogeneous software systems during 
the software development process. 



1 Introduction 

Performance analysis of software systems is a critical issue in the software devel- 
opment process. Modeling is an important and useful approach for performance 
evaluation and system validation and it can provide prediction and comparison 
of design alternatives. 

Software performance engineering deals with the representation and analysis 
of the software system dynamic based on performance models to provide feedback 
in the software development process. Several approaches have been defined in 
the last decade to integrate performance models and specification languages and 
models for deriving or validating non-functional properties of software systems 
[ 44 , 40 , 41 ]. 

Most of these integrated approaches are based on various formal specification 
models ranging form process algebra and Petri net models as well as more recent 
modeling languages such as UML, and they derive performance evaluation mod- 
els based on different formalisms, such as queueing networks, stochastic process 
algebras, stochastic Petri nets and Markov processes. 

An important issue of the integration of quantitative performance analysis 
in the software process is the ability to provide feedback that can be easily 
interpreted by the software designer and system developers. 

Since the different performance models can be applied to represent the soft- 
ware system at different levels of abstraction and have different modeling con- 
straints and solution methods, one can take advantage of the relative merit of 
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each of them. We discuss how the definition of a framework that allows the combi- 
nation of different performance modeling techniques and methods should better 
support performance analysis and validation of complex and heterogeneous soft- 
ware systems, at different levels of abstraction during the software development 
process. Specific software system characteristics such as heterogeneity, scalabil- 
ity and mobility in distributed system could be considered and modeled for the 
software performance analysis. 



2 From Software Specification to Performance Model 

The Software Performance Engineering (SPE) methodology introduced by Smith 
in [44] has been the first comprehensive approach to the integration of perfor- 
mance analysis into the software development process, from the earliest stages 
to the end. More recent approaches focus on the derivation of a performance 
model right from the Software Architecture (SA) specification [2,6,45,15], thus 
allowing for a choice among alternative architectures on the basis of quantitative 
aspects [43]. 

In this section we briefly discuss some recent methodologies for the derivation 
of performance models from SA specifications. First we recall the commonly used 
specification languages focusing on how they are used to derive performance 
models, and then we introduce the main types of performance models and present 
some software performance approaches. 



2.1 Specification Languages 

The recent approaches to derive performance models from SA refer to various 
specification languages, ranging from the Unified Modeling Language (UML) 
[11,47], or other graphical languages such as Message Sequence Charts (MSC) 
[26], to formal specification languages like process algebras and Petri nets. The 
choice of UML is motivated by the fact that UML is nowadays a widely used 
notation for the specification of software systems. It provides various diagrams 
allowing the description of different system views, which capture static and be- 
havioral aspects, interactions among system components and implementation 
details. On the other hand, the choice of a formal specification language based 
on Process Algebras or Petri nets is motivated by the possibility of integrating 
functional and performance aspects and analysis into a unique formalism [21]. 

In order to derive performance models from UML specifications, it is usually 
necessary to complete the UML diagrams with additional performance related 
information, which is associated to the diagrams by means of simple annotations 
or extensions based on stereotypes and tagged values. The recently defined UML 
Profile for Scheduling, Performance and Time [32] allows the adding of such 
information in a standard way. 

The approaches which derive performance models from specification based 
on process algebras and Petri nets usually refer to their stochastic extensions, 
allowing action or firing duration to be expressed by random variables. 
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2.2 Performance Models 

The main classes of performance models are queueing networks (QN), stochastic 
timed Petri nets (STPN) and stochastic process algebras (SPA) [28,21]. Each of 
these classes has its own peculiarities in terms of expressiveness (i.e., the kind 
of system that can be suitably modeled), level of abstraction (i.e., the degree 
of detail needed to describe the system), and efficiency of the solution methods. 
However, QN are traditionally the most commonly applied to evaluate system 
performance, because of their relative high accuracy in performance results and 
their efficiency in model analysis and evaluation. 

Basic QN models represent resource sharing systems. Their extension called 
Extended Queuing Networks (EQN) allows also the representation of other in- 
teresting features of real systems, such as synchronization and concurrency con- 
straints, finite capacity queues, memory constraints and simultaneous resource 
possession [28] . Another extension of QN models is the class of Layered Queuing 
Network (LQN), which models client-server communication patterns in concur- 
rent and/or distributed software systems [42]. 

A performance model can be analyzed by analytical methods or by simu- 
lation, in order to evaluate a set of performance indices such as resource uti- 
lization, throughput, customer response time and others. Simulation is a widely 
used general technique, whose main drawback is the potential high development 
and computational cost to obtain accurate results. On the other hand, analytical 
methods require that the model satisfies a set of assumptions and constraints, 
and are based on a set of mathematical relationships that characterize the system 
behavior. 

The analytical solution is often derived by considering an underlying stochas- 
tic process, usually a discrete-space continuous-time homogeneous Markov chain 
(MC). The solution of the associated MC is in general numerically expensive 
because its state space grows exponentially with the number of components 
of the performance model. However, some efficient analytical algorithms have 
been defined for performance models that satisfy some given constraints, such 
as product-form QN. 

Besides being a possible solution technique for the introduced performance 
models, simulation is also used as a performance model by itself. Existing sim- 
ulation tools provide a specification language for the definition of simulation 
models and a simulation environment to execute simulation experiments. 

2.3 Some Software Performance Approaches 

We discuss now some recent approaches to derive performance models from SA 
specifications. We consider a few main methodologies focusing on the knowledge 
about performance evaluation techniques required to the system designer and 
developer in order to apply the transformation methodology. 

SPE Based Methodologies 

Some of the methods proposed in the literature [46,16,37,36,20] refer to the SPE 
methodology [44], which is based on two models: the software execution model 
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and the system execution model. The former is based on execution graphs and 
represents the software execution behavior; the latter is based on QN models and 
represents the system platform, including hardware and software components. 
The analysis of the software model gives information concerning the resource 
requirements of the software system. The obtained results, together with in- 
formation about the hardware devices, are the input parameters of the system 
execution model, which represents the model of the whole software/hardware 
system. 

Among the approaches based on SPE we consider the one developed by 
Cortellessa and Mirandola in [16]. They propose the PRIMA-UML methodol- 
ogy, which makes a joint use of information from different UML diagrams to 
incrementally generate a performance model representing the specified system. 
SA are specified by using Deployment, Sequence and Use Case diagrams. The 
software execution model is derived from the Use Case and Sequence diagrams, 
and the system execution model from the Deployment diagram. Moreover, the 
Deployment diagram allows the tailoring of the software model with respect to 
information concerning the overhead delay due to the communication between 
software components. Both Use Case and Deployment diagrams are enriched 
with performance annotations concerning workload distribution and devices’ 
parameters, respectively. Hence, in order to apply the PRIMA-UML method- 
ology, the software designer has to know these data and how to specify them. 
As an example of a SPE based approach, we illustrate a simple application of 
the PRIMA-UML methodology. 

Example 1. Consider the architecture of a multiphase compiler shown in Fig- 
ure 1, where the components are the Lexer (lexical analyzer), the Parser (syn- 
tactic analyzer), the Checker (semantic analyzer), the Optimizer and the code 
Generator. The Optimizer is an optional component, in the sense that the user 
can select a simple or optimized compilation. 




Compiler 



Fig. 1. Static description of the multiphase compiler. 

The PRIMA-UML methodology applied to evaluate the performance of the 
compiler system starts with the UML specification. The Use-Case diagram shown 
in Figure 2. (a) considers one type of user and two different use cases, that are 
the simple and the optimized compilation. Note that the Use Case diagram has 
been enriched with the data p and 1 — p representing the probabilities that the 
user asks for a simple or optimized compilation, respectively. We assume that the 
compiler is allocated on a single machine, as shown in the Deployment diagram 
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Fig. 2. Use Case diagram (a) and Deployment diagram (b) of the compiler system. 



in Figure 2.(b). This diagram should be enriched with information concerning 
the specific hardware platform. 

The behavior of the optimized compilation is illustrated by the Sequence 
diagram of Figure 3. (a). The Sequence diagram of the simple compilation can 
be immediately obtained by removing the optimization phase performed by the 
Optimizer component. 




(b) 



Fig. 3. (a) Sequence diagram for the compiler system with code optimization; (b) Meta 
execution graph of the sequential multiphase compiler. 

The PRIMA-UML methodology derives the system execution model (i.e., the 
QN model) from the Deployment diagram, and the software execution model 
from the Use Case and Sequence diagrams. 

Since the compiler is entirely allocated on a single machine, the corresponding 
QN model is simply composed of a single service center. The obtained system 
is completely sequential. However, one can use different allocation strategies to 
distribute the compiler components into a set of connected machines. Then, 
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the corresponding QN model has one service center for each machine, and the 
compilation phases allocated on different machines proceed in parallel. 

Concerning the software execution model, the methodology generates one 
meta execution graph for each Sequence diagram and then merges the obtained 
graphs together into a unique model, which is shown in Figure 3.(b). The execu- 
tion graph refers to a single compiler execution and contains two types of nodes. 
Basic nodes correspond to the various software components and are labeled with 
the name of the performed actions. The case node represents the alternative exe- 
cution of the simple or optimized compilation. The arrows connecting the nodes 
describe the component interactions and the flow of control. 

The term meta execution graph indicates that the activities of the various 
components are just named at this level. The final execution graph, called exe- 
cution graph instance, can be obtained by substituting the action name of each 
node with the corresponding numerical parameters, that define the component 
resource demands. Note that while the methodology automatically generates the 
meta execution graph, the numerical parameters of the final model have to be 
defined by the designer. They are identified on the basis of information derived 
from the system execution model and the knowledge about the resource capabil- 
ities. The final performance model is the QN model parametrized by the analysis 
of the software model and is evaluated to compute the performance indices of 
the software system. 

Petriu and co-authors present in [37,36,20] other approaches based on the 
SPE methodology. They propose three conceptually similar approaches where 
SA are described by architectural patterns, such as pipe and filters, client/server, 
broker, layers, critical section and master-slave, whose structure is specified by 
UML-Collaborations and whose behavior is described by Sequence or Activity 
diagrams. The three methods use graph transformation techniques to build LQN 
models out of complex SA based on combinations of the considered patterns. The 
approaches in [20,36] add performance related information to UML diagrams 
according with the UML Performance Profile [32]. 



Trace Based Methodologies 

Besides the SPE based approaches, other proposals [1,2,45,27,35] still derive QN 
based performance models from SA specification. In particular two approaches 
described in [2,45] are based on the generation and analysis of traces (sequence of 
events/actions) gathered from scenarios describing the behavior of the software 
system under consideration. 

The first approach [1,2] proposes an algorithm that automatically generates 
QN models from SA specifications described by Message Sequence Charts (MSC) 
[1] or by Labeled Transition Systems (LTS) [2]. The approach analyzes the SA 
dynamic specification in terms of the execution traces (sequences of events) 
it defines, in order to single out the maximum degree of parallelism among 
components and their dynamic dependencies. A key point of this approach is 
the assumption that the SA dynamics, described by MSC or LTS, is the only 
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available system knowledge. This allows the methodology to be applied when 
information concerning the system implementation or deployment are not yet 
available. An example of application of this methodology to the compiler system 
of Example 1 is given in [2], where three different SA are compared. We refer 
to [2] for the complete description of the example and for the derivation of the 
corresponding QN models. 

The second trace-based approach has been developed by Woodside et al. 
[45], and propose the automatic derivation of a LQN model from a commercial 
software design environment called ObjecTime Developer [33], by means of an in- 
termediate prototype tool called PAMB (Performance Analysis Model Builder) . 
ObjecTime Developer allows the designer to describe a set of communicating 
actor processes, each controlled by a state machine, plus data objects and proto- 
cols for communications. It is possible to “execute” the design over a scenario by 
inserting events, stepping through the state machines, and executing the defined 
actions. Moreover, the tool can generate code from the system design, that can 
be used as prototype or as a first version of the product. The approach in [45] 
takes advantage of such code generating and executing scenarios capabilities for 
model-building: the prototype tool PAMB, integrated with ObjecTime Devel- 
oper, keeps track of the execution traces, and captures the resource demands 
obtained by executing the generated code in different execution platforms. The 
trace analysis allows the building of the various LQN submodels, one for each 
scenario, which are then merged into a global model, while the resource de- 
mands data provides the model parameters. After solving the model through 
an associated model solver, the PAMB environment reports the performance re- 
sults through performance annotated MSC and graphs of predictions. Note that 
this approach requires less knowledge about performance aspects to the software 
designer, since the performance parameters are automatically evaluated by the 
PAMB tool. 

Methodologies Based on Formal Specification Languages 

Some authors propose the translation of UML models into stochastic Petri net 
models or stochastic process algebra specifications [38,29,10] in order to per- 
form quantitative evaluation of software systems. However, the more mature 
approaches based on formal specification languages such as STPN and SPA 
do not combine UML with SPA or STPN. These methods allows integrating 
functional and non-functional aspects into a unique reference framework and 
model for both SA specification and performance analysis. Formal specification 
languages make SA specification and its functional analysis more rigorous and 
well-founded. 

However, from the performance evaluation viewpoint, the analysis of such 
models usually refers to the numerical solution of the underlying Markov chain 
which can easily lead to numerical problems due to the state space explosion. 
Another disadvantage of these approaches is the knowledge required to the soft- 
ware designer to specify the software system with process algebras or Petri nets, 
and to define the appropriate parameters for action or firing duration. 
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In particular several stochastic extensions of process algebras have been re- 
cently proposed, such as TIPP (Time Processes and Performability evaluation) 
[18], EMPA (Extended Markovian Process Algebra) [9,8] and PEPA (Perfor- 
mance Evaluation Process Algebra) [24]. The main differences between these 
SPA concern the expressivity of their languages. They associate exponentially 
distributed random variables to actions and provide the generation of a Markov 
chain out of the semantic model (a Labeled Transition System enriched with 
time information) of a specified system. Furthermore, they are supported by ap- 
propriate tools, the TIPP tool. Two Towers and PEPA Workbench, respectively. 

In this setting, Balsamo et alt. introduced in [6] a SPA based Architectural 
Description Language (ADL) called iEmilia, whose semantics is given in terms 
of EMPA specifications. The introduction of an ADL aims at easing the software 
designer in identifying the system components and their interconnections. fEmilia 
provides a formal framework for the compositional, graphical, and hierarchical 
modeling of software systems and is equipped with some functional checks for the 
detection of possible architectural mismatches. Moreover the authors propose a 
systematic approach to the translation of fEmilia specifications into basic QN 
models, with the aim of taking advantage of the orthogonal strengths of the 
two formalisms: formal techniques for the verification of functional properties 
for fEmilia (SPA in general), and efficient performance analysis for QN. 

The example described in Example 1 is applied for this methodology in [6], 
where its iEmilia specification and its translation into the QN model is presented. 

Simulation Based Methodologies 

Another class of integrated software performance approaches are based on sim- 
ulation models. The method proposed by De Miguel et alt. in [17] uses sim- 
ulation packages in order to define a simulation model, whose structure and 
input parameters are derived from UML diagrams. The approach focuses on 
real-time systems and proposes extensions of UML diagrams (based on the use 
of stereotypes, tagged values and stereotyped constraints) to express temporal 
requirements and resource usage. The SA is specified using the extended UML 
diagrams without restrictions on the type of diagrams to be used. Like some pre- 
vious approaches, this technique requires the software designer to know how to 
specify the timing and performance parameters in order to use the whole frame- 
work. The resulting diagrams are used as input for the automatic generation of 
the scheduling and simulation models via two components called Analysis Model 
Generator (AMG) and Simulation Model Generator (SMG), respectively. In par- 
ticular, SMG generates OPNET models [34], by first generating one submodel 
for each application element and then combining the obtained submodels into 
a unique simulation model. The approach provides also a feedback mechanism 
by including the simulation results in the tagged values of the original UML 
diagrams. 

To conclude, we point out that most of the existing methodologies do not yet 
provide a complete framework for the automatic derivation of performance mod- 
els from SA specification. Most of them do not yet integrate the various steps 
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concerning software specification, model transformation, performance evaluation 
and feedback to the software designer into a unique environment properly sup- 
ported by tools. In particular just a few approaches address the issue of reporting 
or interpreting the performance results at the SA level. However, this is an im- 
portant feature which has to be considered in order to make the performance 
evaluation of SA really complete and useful in the software process. 

3 Open Problems and Perspectives 

Performance modeling and analysis in the software development process is based 
on the generation of appropriate performance models that allow high integration 
of functional and behavioral models, as discussed in the previous section. 

For each class of performance models, from queueing networks to stochas- 
tic process algebras, stochastic Petri net to Markov processes, we can identify 
specific advantages, constraints and peculiarities in terms of expressiveness, ef- 
ficiency of the solution methods and level of abstraction. A detailed review of 
software performance approaches can be found in [5]. In this section we discuss 
some open problems and perspectives in software performance modeling. 



An Integrated Ftamework for Software Performance 

We can take advantage of the characteristics of the modeling formalism to define 
a combined or integrated framework for software performance analysis, by com- 
bining different types of models. Such framework should better support perfor- 
mance analysis and validation of complex and heterogeneous software systems 
at different levels of abstraction during the software development process. By 
referring to different levels of abstraction in the development process, one can 
identify and select the appropriate performance model that can be applied to 
evaluate the software system. This corresponds to model the appropriate fea- 
tures and details of the software system that allow the description its dynamic 
behavior. 

This performance modeling approach is illustrated in Figure 4. Starting from 
an appropriate software specification, from the description of its dynamic behav- 
ior one can choose and derive a performance model that allows representing the 
relevant characteristics at the selected level of abstraction. By applying the cor- 
responding transformation algorithm one defines a performance model, selecting 
from analytical models, such as QN Markov chains, STPN and SPA, simulation 
models and possibly other types of models such as hybrid models. 

Once the appropriate performance model has been identified, one can apply 
the corresponding performance evaluation methods. When an analytical perfor- 
mance model is selected, solution methods can be symbolic for some particular 
classes, such as some simple Markov chains and the class of product-form QN 
[28], so allowing an easier parametric analysis and result interpretation at the 
software level. More generally, analytical models can be analyzed through ap- 
proximate numerical algorithms, such as for EQN and LQN [42], and for more 
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Fig. 4. Performance modeling of software specification. 



complex Markov chains. STPN and SPA are usually analyzed by defining and nu- 
merically solving the underlying Markov chain. Simulation models are analyzed 
by discrete simulation techniques. The analysis and solution of the performance 
model requires the instantiation of system parameters, whose type and number 
depend on the abstraction level of the model. Parameter instantiation can be 
determined by a scenario driven approach. 

Hence, the selection of the performance solution method depends on the se- 
lected performance models and parameters and can provide different degrees of 
accuracy in evaluating the performance figures of merit. The level of abstraction 
of the model also determines the number of parameters to be derived. Hierar- 
chical modeling and a top-down approach can be applied to increase the level 
of details in successive steps of the modeling process, as discussed in the next 
subsection. 

An important feature of this performance modeling framework, based on 
various software performance models, is to provide the designer a feedback that 
has to be easily interpreted by the software designer without specific knowledge of 
performance modeling techniques. This feature strongly depends on the selected 
performance modeling approach. 

Therefore the selection of the appropriate model should be provided by the 
performance environment and driven by several issues, as discussed in the pre- 
vious section. These include the software specification model or language, the 
relevant characteristics of the software systems, the accuracy of the performance 
analysis required in the software development step and the ability to provide 
feedback to the software designer. 
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Specific software system characteristics such as heterogeneity, scalability and 
mobility in distributed systems could be considered and represented by the ap- 
propriate model for the software performance analysis. For example a few recent 
approaches have been proposed for performance analysis of mobile software sys- 
tems, e.g. [15,19]. 

Another issue in selecting the appropriate software performance methodol- 
ogy is the availability of supporting tools. Although several methodologies and 
approaches have been proposed, so far only few of them have been completely 
automated. Some prototypes have been recently presented, as discussed in the 
previous section, such as the PAMB tool for real-time interactive software based 
on LQN [45], UCM2LQN tool [35] based on Use Case Maps and various tools 
for Stochastic Process Algebras, e.g., TIPP [18], EMPA [9,8] and PEPA [24]. 

Hierarchical Modeling 

An integrated software performance environment should allow successive refine- 
ments of performance modeling and tools based on various models, corresponding 
to different levels of abstraction, to be applied at different phases of the software 
development process, driven by the specified requirements. Then the scheme il- 
lustrated in Figure 4 can be iterated by considering different performance models 
to obtain more complete performance results. Additional information should be 
possibly integrated in successive steps to define either different or more refined 
performance models that allow further software system evaluation. 

Considering a top-down approach, at the high levels of abstraction in the 
software development process we should select simpler high-level performance 
models with a limited number of parameters so that they can be easily derived 
by a possible incomplete software specification and some hypotheses on the pos- 
sible scenarios of interest. Models like Use Case Maps and simple product-form 
QN appear to be possible appropriate choices at this step, and simple solution 
techniques, such as symbolic solution methods or simple bound analysis allow 
the evaluation of performance results also from incomplete descriptions of the 
software specification. At more detailed levels of abstraction in the software de- 
velopment process a more complete and detailed software specification can drive 
us to apply software performance methodologies based on more sophisticated 
performance models. Depending on the considered specification language and 
the goal of the analysis we can consider integrated methodologies based on SPA, 
EQN, LQN and STPN. In particular by applying SPA or STPN one can take 
advantage of the integration of the performance and specification formalism. 
Such more detailed models usually require a more complete set of system pa- 
rameters to be instantiated and possibly a high computational complexity in the 
evaluation of performance indices. 

In this framework it is relevant to investigate the application of methodologies 
to derive structured performance models at different levels of abstraction, where 
the solution of a model at a given level can be obtained extending the solution 
of a related model at the previous level [12,14]. These methodologies are based 
on the decomposition and aggregation principle and can be applied to various 
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classes of performance models, from Markov chain to QN, to STPN and SPA 
[28,25,3,30]. 

In line with hierarchical modeling in engineering context, describing a com- 
plex system with a hierarchical performance model means applying a top-down 
decomposition technique. Starting from an abstract model of the system, each 
step defines a more refined model of the same system, which is composed of 
interacting submodels that can be further refined in successive steps. Perfor- 
mance analysis of hierarchical models usually starts from the most detailed 
model and requires the application of a bottom-up aggregation technique [14]. 
Roughly speaking, the model of each level is analyzed first by solving each sub- 
model in isolation and then by aggregating all the submodels into the model of 
the higher level. An aggregation technique defines a simpler and smaller model 
that is equivalent to the original one with respect to some performance indices. 
For example, flow-equivalent aggregation for product-form QN defines an aggre- 
gated QN where each subnetwork is substituted by a single service center. Such 
smaller QN is equivalent to the original one in terms of average performance 
indices and queue length distribution. Similarly, lumping of Markov processes 
and aggregation of SPA and STPN define new reduced models that are equiva- 
lent to the original ones with respect to the steady state distribution [28,25,30]. 
Performance analysis of hierarchical models can be also carried out through a 
top-down approach by disaggregation techniques. These methods define a more 
detailed performance model starting from a high-level model, by specifying pa- 
rameters constraints so that the new disaggregated model is equivalent to the 
original one with respect to a set of performance indices. For example, synthesis 
of product-form QN defines a disaggregated queueing network from a smaller 
network, where a service center is substituted by a larger subnetwork, keeping 
the same average performance indices and queue length distribution [7]. 

In this framework of hierarchical performance modeling one can also apply a 
hybrid approach to analyze the different submodels: hybrid models apply mixed 
analytical and simulation techniques to evaluate the solution of various submod- 
els and to combine their results in order to evaluate the performance of the whole 
system. Hybrid methods exploit the specific features of each submodel to take 
advantage of the relative merit of the different solution technique, i.e., generality 
of simulation and efficiency of analytical methods. 

Another relevant issue in this framework of software performance is to inte- 
grate various models into the same framework, to identify and take advantage of 
the specific characteristics of the various classes of performance models. Starting 
from the software performance methodologies that derive a class of performance 
models from the software specification, some examples of integrated or combined 
approaches have been recently presented. The comparison of LQN and SPA and 
their application to performance validation is described in [22] . The combination 
of SPA and basic QN models for SA analysis have been introduced in [6] to take 
advantage of formal techniques to verify functional properties for the former 
model and efficient solution algorithms for the latter. The combination of QN 
and generalized STPN for the solution of complex models of system behavior 
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is described in [4]. An automated software design performance environment has 
been presented in [45] , and a performance approach that considers software in a 
distributed mobile environment has been recently introduced in [15]. 

Further research has to investigate a more complete integration of different 
models and solution techniques, including simulation and hybrid methods, into 
the software performance process, exploiting the identification of appropriate 
and representative models and the problem of how to efficiently feedback the 
performance results at the software specification level. 
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Abstract. A variety of programming accidents, i.e., models, methods, artifacts, 
and tools, are examined to determine that each has a step that programmers find 
very painful. Consequently, they habitually avoid or postpone the step. This pain 
is generally where the programming accident meets requirements, the essence of 
software, and their relentless volatility. Hence, there is no silver bullet. 



1 Introduction 

The call for papers (http://www.dsi.unive.it/~mont2002/topics.html) for the 2002 Mon- 
terey Workshop on Radical Innovations of Software and Systems Engineering in the 
Future says of the object-oriented programming methods introduced in the last decade, 
“There is no proof and no evidence that software productivity has increased with the 
new methods”'. The call for papers argues that as a consequence of this and other rea- 
sons, there is an urgent need for new “post object-oriented” software engineering and 
programming techniques. However, there is no proof, evidence, or guarantee that any 
such new technique will increase productivity any more than object-oriented techniques 
have. Indeed, the past failures of any method to significantly increase productivity is 
the strongest predictor that any new technique will fare no better. In other words, what 
makes you, who designs new methods, think you can do better? 

This paper tries to get to the root of why any given new programming technique has 
not improved productivity very much. This paper is, as the call for papers requires, an 
attempt “to analyze why some ideas were or were not successful” with the choice of 
“were not”. 

This paper is about building computer-based systems (CBS). Since the most flexible 
component of a CBS is its software, we often talk about developing its software, when 
in fact we are really developing the whole CBS. In this paper, “software” and “CBS” 
are used interchangeably. 

This paper is based on personal observation. Sometimes, I describe an idea based 
solely on my own observations over the years. Such ideas carry no citation and have no 

* Actually, this claim is a bit too strong. There is a feeling that object orientation has improved 
programming a bit, and there are even some data [33], but it is clearly not the silver bullet that 
it was hoped, and even hyped, to be. 



M. Wirsing et al. (Eds.): RISSEF 2002, LNCS 2941, pp. 50-74, 2004. 
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formal or experimental basis. If your observations disagree, then please write your own 
rebuttal. 

Sometimes, I give as a reason for doing or not doing something that should not be 
or should be done what amounts to a belief or feeling. This belief or feeling may be 
incorrect in the sense that it is not supported by the data. Whenever possible, I alert the 
reader of this mode by giving the belief-or-feeling-based sentence in italics. 

2 Programming Then and Now 

I learned to program in 1965. I can remember the first large program I wrote in 1966 
outside the class room for a real-life problem. It was a program that implemented the 
external functionality of Operation Match, a computer-based dating and matchmaking 
service set up in the mid 1960s. I wrote it for my synagogue youth group in order that 
it could have a dance in which each person’s date for the dance was that picked by 
a variation of the Operation Match software. The dance and the software were called 
“Operation Shadchan”^. 1 got a hold of the questionnaire for Operation Match, which 
was being used to match a new client of one gender with previously registered clients of 
the opposite gender. Each client filled out the form twice, once about him or herself and 
the second time about his or her ideal mate. For each new client, the data for the client 
would be entered. Then the software would hnd all sufficiently good matches with the 
new clients from among the previously registered clients. Presumably, the matches had to 
be both good and balanced; that is, the total number of questions for which each answered 
the way the other wanted had to be greater than a threshold and the difference between 
the number of matches in each direction had to be smaller than another threshold. I 
adapted this questionnaire for high school purposes. For example, 1 changed “Do you 
believe in sex on the first date?” to “Do you believe in kissing on the first date?”^. 

1 then proceeded to write a program. I remember doing requirements analysis at the 
same time as 1 was doing the programming in the typical seat-of-the-pants build-it-and- 
fix-it-until-it-works method of those days: 

- discover some requirements, 

- code a little, 

- discover more requirements, 

- code a little more, 

- etc, until the coding was done; 

- test the whole thing, 

- discover bugs or new requirements, 

- code some more, etc. 

The hrst requirements were fairly straightforward to identify. Since this matching was 
for a dance, unlike with Operation Match, each person would be matched with one and 
only one person of the opposite gender"^. Obviously, we had to make sure that in the 
input set, the number of boys was equal to the number of girls, so that no one would 

^ “Shadchan” is Yiddish for “Matchmaker”. The “ch” in “shadchan” is pronounced as the “X” in 
“TpX”. One person attending the dance thought the name of the dance was “Operation Shotgun”. 

^ Remember, this was during the mid 1960s! 

It was assumed that each person wanted someone of the opposite gender. 
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have the stigma of being unmatched by the software. The next requirements were not so 
easy to identify. Each boy and each girl should be matched to his or her best match. So, 
I wrote a loop that cycled through each person and for each, cycled through each other 
person of the opposite gender to find the best match. But whoa! what is a match? Ah, it 
cannot be just one way. It must be a mutually balanced match. But double whoa! I have 
to remove from the list of those that can be cycled through in either loop those that have 
been matched before. But triple whoa! Suppose the best mutual match for someone is 
among those not considered because that best mutual match has already been matched 
to someone else, and that earlier match is not as good. Worse than that, suppose that 
what is left to match with someone are absolute disasters for the someone. This simple 
algorithm is not so hot. 

In those days and at that age, couples in which the girl was taller than the boy was 
a disaster, especially if the difference was big. Also, it was not considered so good if 
the girl of a couple were older than the boy. Therefore, to avoid being painted into a 
disastrous-match corner, I decided to search in a particular order, from hardest-to-find- 
non-disastrous matches to easiest. That is, I searched for matches for the tallest girls and 
shortest boys first and the shortest girls and tallest boys last. Presumably the tallest boys 
get assigned fairly early to the tallest girls and the shortest girls would get assigned fairly 
early to the shortest boys. I randomly chose the gender of the first person to be matched 
and alternated the gender in each iteration of the outer loop. To help avoid disastrous 
matches, I gave extra weight to the height and age questions in calculating the goodness 
of any potential match. Each “whoa” above represents a scrapping of previously written 
code in favor of new code based on the newly discovered requirements. Thus, I was 
discovering requirement flaws and correcting them during coding as a result of what I 
learned during coding. 

The biggest problem I had was remembering all the requirements. It seemed that 
each thought brought about the discovery of more requirements, and these were piling 
up faster than I could modify the code to meet the requirements. I tried to write down 
requirements as I thought of them, but in the excitement of coding and tracking down the 
implications of a new requirement, which often included more requirements, 1 neglected 
to or forgot to write them all down, only to have to discover them again or to forget them 
entirely. 

Basically, programming felt like skiing down a narrow downhill valley with an 
avalanche following me down the hill and gaining on me. 

Nowadays, we follow more systematic methods. However, the basic feelings have 
not changed. Since then, I have maintained and enhanced a curve fitting application for 
chemists^ . I built a payroll system. I have participated in the writing of a collection of text 
formatting software. I have watched my graduate students develop tools for requirements 
engineering. I watched my ex-wife build a simulation system. I have watched my ex-wife 
and former students and friends involved in startups building large CBSs. To me and, 
I am sure, the others, programming still feels like skiing with an avalanche following 
closely behind. I see all the others undergoing similar feelings and being as empathic as 



^ This was my second system, and it suffered Brooks’s second system syndrome [18], as I tried 
to build a super-duper, all-inclusive, fancy whiz-bang general curve fitting application with all 
sorts of fantastic options. 
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I am, I get the same skiing feeling. No matter how much we try to be systematic and to 
document what we are doing, we forget to write things down, we overlook some things, 
and the discoveries seem to grow faster than the code. 

The real problem of software engineering is dealing with ever-changing require- 
ments. It appears that no model, method, artifact, or tool offered to date has succeeded 
to put a serious dent into this problem. I am not the hrst to say so. Fred Brooks and 
Michael Jackson, among others, have said the same for years. Let us examine their 
arguments. 

3 The Search for a Silver Bullet 

Some time ago, Fred Brooks, in saying that there is no software engineering silver 
bullet [17] classihed software issues into the essence and the accidents. The essence 
is what the software does and the accidents are the technology by which the software 
does the essence or by which the software is developed. That is, the requirements are the 
essence, while the language, tools, and methods used are the accidents. He went on to 
say, “The hardest single part of building a software system is deciding precisely what to 
build.... No other part of the work so cripples the resulting system if it is done wrong. No 
other part is more difficult to rectify later.” This quotation captures the essential difficulty 
with software that must be addressed by any method that purports to alter fundamentally 
the way we program, that purports to make programming an order of magnitude easier, 
that purports to be the silver programming bullet we have all been looking for. Heretofore, 
no single method has put a dent into this essential problem, although all the discovered 
methods have combined to improve programming by at least an order of magnitude since 
1968, the year the term “software engineering” was invented [59]. Bob Glass reviews 
the data showing the modest improvements of each of a variety of techniques, methods, 
and models [33]. 

Moreover, Brooks, based on his experience, predicted that “There is no single devel- 
opment, in either technology nor management technique, which by itself promises even 
one order-of-magnitude improvement within a decade in productivity, in reliability, in 
simplicity.” He made this prediction in 1986 when he first published “No Silver Bullet” 
in Information Processing ’86. Since we are now well past a decade after 1986, and 
no such single technology or management technique has appeared, he has been proven 
correct. He added a slightly stronger, but still conditional, prediction with which I agree. 
“I believe the hard part of building software to be the specification, design, and testing 
of this conceptual construct, not the labor of representing it and testing the fidelity of 
the representation. We still make syntax errors, to be sure; but they are fuzz compared 
to conceptual errors in most systems. If this is true, building software will always be 
hard. There is inherently no silver bullet.” Because we will always be building systems 
at the new frontiers opened by the latest advances in the accidents, I believe that the 
antecedent of this conditional statement, that conceptual errors are the hardest kind to 
hnd, will always be true. Therefore, / believe that the conclusion will always be true and 
that there is inherently no silver bullet. 

* This paper, published in IEEE Computer in 1987 is a reprint of an earlier, less accessible 
publication in the 1986 IFIP proceedings [16], and is in turn reprinted in the currently more 
accessible 20th Annniversary Edition of The Mythical Man-Month [18]. 
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Make no bones about it. Software productivity has improved since the publication 
of “No Silver Bullet” in 1986 because of the accumulative effect of all the accidental 
advances. Ironically, each such advance makes additional advances more and more 
difficult, because as each accidental difficulty is solved, what is left is more and more 
purely of essence. 

The obvious question is “Why is there no silver bullet, and why can there not be 
a silver bullet?” The contention of this paper is that every time a new method that is 
intended to be a silver bullet is introduced, it does make many parts of the accidents 
easier. However, as soon as the method needs to deal with the essence or something 
affecting or affected by the essence, suddenly one part of the method becomes painful, 
distasteful, and difficult, so much so that this part of the method gets postponed, avoided, 
and skipped. Consequently, the method ends up being only slightly better than no method 
at all in dealing with essence-borne difficulties. 

But, what is so difficult about understanding requirements? I mean, it should be 
possible to sit down with the customer and users, ask a few questions, understand the 
answers, and then synthesize a complete requirements specification. However, it never 
works out that way. Michael Jackson, Paul Clements, David Parnas, Meir Lehman, 
Bennet Lientz, Burton Swanson, and Laszlo Belady explain why. 

4 Requirements Change 

Michael Jackson, in his Keynote address at the 1994 International Conference on Re- 
quirements Engineering [42] said that two things are known about requirements: 

1 . They will change. 

2. They will be misunderstood. 

The first implies that a CBS will always have to be modified, to accommodate the changed 
requirements. Even more strongly, there ain’t no way that requirements are not gonna 
change, and there is as much chance of stopping requirements change as there is stopping 
the growth of a fully functioning and heartily eating teenager. The second implies that a 
CBS will always have to be modified, to accommodate the changes necessitated by better 
understanding, as the misunderstandings are discovered. Clements and Parnas describe 
how difficult it is to understand everything that might be relevant [62]. 

Meir Lehman [50] classifies a system that solves a problem or implements an appli- 
cation in some real world domain as an E-type system. He points out that once installed, 
an E-type system becomes inextricably part of the application domain so that it ends up 
altering its own requirements. 

Certainly, not all changes to a CBS are due to requirement changes, but the data show 
that a large majority of them are. Bennett Lientz and Burton Swanson found that of all 
maintenance of application software, 20% deal with correcting errors, and 80% deal 
with changing requirements. Of the requirement changes, 31% are to adapt the software 
to new platforms, and 69% are for perfecting the software, to improve its performance 
or to enhance its functionality [53]. 

Laszlo Belady and Meir Lehman observed the phenomenon of eventual unbounded 
growth of errors in legacy programs that were continually modified in an attempt to fix 
errors and enhance functionality [7,8]. That is, as programs undergo continual change 
their structure decays to the point that it is very hard to add something new or change 
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Fig. 1. Belady-Lehman Graph. 

something already there without affecting seemingly unrelated parts of the program in 
a way that causes errors. It can he difficult even to find all the places that need to he 
modified. The programmers make poor guesses and the program, if it even runs, behaves 
in strange and unpredicted ways. They modeled the phenomenon mathematically and 
derived a graph like that of Fig. 1, showing the expected number of errors in a program 
as a function of time, as measured by the ordinal numbers of releases during which 
modifications are made. In practice, the curve is not as smooth as in the figure, and it 
is sometimes necessary to get very far into the upswing before being sure where the 
minimum point is. The minimum point represents the software at its most bug-free 
release. After this point, during what will be called the Belady-Lehman (B-L) upswing, 
the software’s structure has so decayed that it is very difficult to change anything without 
adding more errors than have been fixed by the change. 

The alternative to continuing on the B-L upswing for a CBS is to roll back to the 
best version, that is, the version that existed at the minimum point. Of course, rolling 
back assumes that all versions have been saved. All the bugs in this best version are 
declared to be features, and no changes are ever made in the CBS from then on. Usually 
not changing a CBS means that the CBS is dead, that no one is demanding changes 
because no one is using the software any more. However, some old faithful, mature, and 
reliable programs e.g, cat and other basic UNIX applications, vi, and ditroff^, have gone 
this all-bugs-are-features route. The user community has grown to accept, and even, 
require that they will never change. If the remaining bugs of the best version are not 
acceptable features or the lack of certain new features begins to kill usage of the CBS, 
then a new CBS has to be developed from scratch to meet all old and new requirements, 
to eliminate bugs, and to restore a good structure to make future modifications possible. 
Another alternative that works in some special cases is to use the best version as a feature 
server for what it can do well and to build a new CBS that implements only the new and 
corrected features and has the feature server do the features of the best version of the 
old CBS. 

^ Well, at least / think so! One great thing about these programs that have not been modified 
since the 1980s is that their speed doubles every 18 months! 
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The time at which the minimum point comes and the slopes of the curves before and 
after the minimum point vary from development to development. The more complex the 
CBS is, the steeper the curve tends to be. Moreover, most of the time, for a carefully 
developed CBS, the minimum point tends to come in later releases of that CB S . However, 
occasionally, the minimum point is passed during the development of the first release, as a 
result of extensive requirements creep during that initial development. The requirements 
have changed so much since the initial commitment to architecture that the architecture 
has had to be changed so much that it is brittle. It has become very hard to accommodate 
new or changed requirements without breaking the CBS . Sometimes, the minimum point 
is passed during the initial development as a result of code being slapped together into 
the CBS with no sense of structure at all. The slightest requirements change breaks the 
CBS. 

5 Purpose of Methods 

One view of software development methods is that each method has as its underlying 
purpose to tame the B-L graph for the CBS developments to which it is applied. That 
is, each method tries to delay the beginning of the B-L upswing or to lower the slope of 
that B-L upswing or both. For example, Information Hiding [61] attempts to structure a 
system into modules such that each implementation change results in changing only the 
code, and not the interface, of only one module. If such a modularization can be found, 
then all the code affecting and affected by any implementation change is confined to 
one module. Thus, it is easier to do the modifications correctly and without adversely 
affecting other parts of the system. Hence, arrival at the minimum point is delayed and 
the slope of the upswing is reduced. 

In this sense, each method, if followed religiously, works. Each method provides the 
programmer a way to manage complexity and change so as to delay and moderate the 
B-L upswing. However, each method has a catch, a fatal flaw, at least one step that is a 
real pain to do, that people put off. People put off this painful step in their haste to get 
the software done and shipped out or to do more interesting things, like write more new 
code. Consequently, the software tends to decay no matter what. The B-L upswing is 
inevitable. 

What is the pain in Information Hiding? Its success in making future changes easy 
depends on having identified a right decomposition. If a new requirement comes along 
that causes changes that bridge several modules, these changes might very well be harder 
than if the code were more monolithic, simply because it is generally easier on tools to 
search within one, even big, module than in several, even small, modules [25,36]. More- 
over, future changes, especially those interacting with the new requirement, will likely 
cross cut [45] module boundaries^. Consequently, it is really necessary to restructure 
the code into a different set of modules. This restructuring is a major pain, as it means 
moving code around, writing new code, and possibly throwing out old code for no exter- 

* For an example that requires minimum explanation, consider two independently developed 
modules, for implementing unbounded precision integer and real arithmetic. Each can have 
its implementation change independently of the other. However, if the requirement of inter- 
type conversion is added, suddenly the two modules have to be programmed together with 
representations that allow conversion. 
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nally observable change in functionality. It is something that gets put off, causing more 
modifications to be made on an inappropriate structure. 

The major irony is that the reason that the painful modifications are necessary is 
that the module structure no longer hides all information that should be hidden. Because 
of changes in requirements, there is some information scattered over several modules 
and exposed from each of these modules. Note that these changes are requirements 
changes rather than implementation changes, which continue to he effectively hidden. 
The painful modifications being avoided are those necessary to restore implementation 
information hiding, so that future implementation changes would he easier. Without the 
painful changes, all changes, both implementation and requirements-directed, will be 
painful. This same pain applies to any method based on Information Hiding, such as 
Object-Oriented Programming. 

In the subsequent sections, each of a number of models, methods, and tools is exam- 
ined to determine what its painful step is. In some cases, the whole model, method, or 
tool is the pain; in others, one particular step is the pain. No matter what, when people 
use these models, methods, and tools, they tend to get stopped by a painful step. 

Despite the rhetoric, please understand that I am not opposed to any of the methods I 
am describing below. 1 have used some of them successfully. 1 am merely trying to show 
where each method becomes painful to use. A mature software engineer would continue 
to use them even when they are painful. 

6 Development Models and Global Methods 

This section considers several development models and general programming methods 
to identify their painful parts. The set chosen is only a sampling. Space limitations and 
reader boredom preclude covering more. It is hoped that after reading these, the reader is 
able to identify the inevitable pain in his or her own favorite model or method. In fact, for 
many models and methods, the pain lies in precisely the same or corresponding activities, 
all in response to requirements change. The models covered are the Waterfall Model and 
Requirements Engineering. The general methods covered are Structured Programming, 
Extreme Programming, Program Generation, Rapid Prototyping, and Eormal Methods. 
A fuller set of models and programming models are covered in a technical report of the 
same title available at: 

http://se.uwaterloo.ca/~dberry/FTP_SITE/tech.reports/painpaper.pdf 
6.1 Waterfall Model 

The waterfall model [67] is an attempt to put discipline into the software development 
process by forcing understanding and documentation of the requirements before going 
on to design, by forcing understanding and documentation of design before going on to 
coding, by forcing thorough testing of the code while coding each module, etc. The model 
would work if the programmers could understand a stage thoroughly and document it 
fully before going on to the next stage [62]. However, understanding is difficult and 
elusive, and in particular, documentation is a pain. The typical programmer would prefer 
to get on to coding before documenting. Consequently, some programmers consider the 
whole model to be a pain, because it tries to force a disciplined way of working that 
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obstructs programmers from getting on with the coding in favor of providing seemingly 
endless, useless documentation. However, even for the programmers who do believe 
in discipline, the waterfall becomes a pain in any circumstance in which the waterfall 
cannot be followed, e.g., when the full requirements are learned only after significant 
implementation has been carried out or when there is significant repeated backtracking, 
when new requirements are continually discovered. 



6.2 Structured Programming 

I can recall the first systematic programming method I learned, used, and taught, from 
1973 until it fell out of fashion in the mid 1980s, namely. Structured Programming or 
Stepwise Refinement [75,23]. After having done build-it-and-fix-it programming for 
years. Structured Programming appeared to be the silver bullet, at last, a way to put 
some order into the chaotic jumble of thoughts that characterized my programming, at 
last, a way to get way ahead of or to the side of the avalanche that was coming after me 
all the time. 

In fact, I found that Structured Programming did work as promised for the devel- 
opment of the first version of any CBS. If I used the clues provided by the nouns that 
appeared in more than one high-level statement [9,11], Structured Programming did 
help me keep track of the effects of one part of the program on another. It did help me 
divide my concerns and conquer them one-by-one, without fear of forgetting a decision 
I had made, because these decisions were encoded in the lengthy, well-chosen names of 
the abstract, high-level statements that were yet to be refined. Best of all, the structured 
development itself was an ideal documentation of the structure of the program. 

However, God help me if I needed to change something in a program developed by 
stepwise refinement, particularly if the change was due to an overlooked or changed 
requirement. I was faced with two choices: 

1 . Patch the change into the code in the traditional way after a careful analysis of ripple 
effects; observe that the documented structured development assists in finding the 
portions of the code affected by and affecting the change. 

2. Redo the entire structured development from the top downward, taking into account 
the new requirement and the old requirements, all in the right places in the refinement. 

The problems with the first choice are that: 

1 . no matter how careful I was, always some ripple effects were overlooked, and 

2. patching destroys the relation between the structured development and the code, so 
that the former is no longer accurate documentation of the abstractions leading to 
the code. This discrepancy grows with each change, thus hastening the onset of the 
B-L upswing®. Thus, the new code contradicts the nice structure imposed by the 
structured development. Moreover, the names of the high level abstractions that get 
refined into code no longer imply their refinements. 

® It is clear that there is a disrepancy, because if the abstractions had derived the new code, then 
the new code would have been there before. 
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Therefore, the correct alternative was the second, to start from scratch on a new structured 
development that recognizes the modified full set of requirements. However, then the 
likelihood is that the new code does not match the old code. Most structured programmers 
do this redevelopment with an eye to reusing as much as possible. That is, whenever one 
encounters a high-level statement with identical name and semantics as before, what it 
derived before is put there. However, the programmer must be careful to use the same 
high-level statements as refinements whenever possible, and he or she must be careful 
that in fact the same semantics is wanted as before and that he or she is not self deluding 
to the point of falsely believing a high-level statement has the same semantics as before. 

This second alternative turned out to be so painful that I generally opted to the first 
alternative, patching the code and thus abandoned the protection, clarity, and documen- 
tation offered by Structured Programming. 

About that time, I learned the value of faking it. Do the modification by patching up 
the code, and then go back and modify the original structured development to make it 
look like the new program was derived by Structured Programming. However, faking 
it was also painful, and soon, unless I was required to do so for external reasons, e.g., 
preparing a paper for publication or a contract, I quickly stopped even faking it. Adding 
to the pain of faking it was the certainty of not doing the faking perfectly and being 
caught. It was only later that David Parnas and Paul Clements legitimized faking it [62] 
and relieved my guilt. 

6.3 Requirements Engineering 

The basic premise of requirements engineering is spend sufficient time up front, be- 
fore designing and coding, to anticipate all possible requirements and contingencies, 
so that design and coding consider all requirements and contingencies from the begin- 
ning [13,60]. Consequently, fewer changes are required, and the B-L upswing is both 
delayed and moderated. Data show that errors found during requirements analysis cost 
one order of magnitude less to fix than errors found during coding and two orders of 
magnitude less to fix than errors found during operation [15]. These economics stem 
from the very factors that cause the B-L upswing, namely, the fact that in a full running 
program, there is a lot more code affecting and affected by the changes necessary to fix 
an error than in its requirements specification. There are data and experiences that show 
that the more time spent in requirements engineering, the smoother the implementation 
steps are [31,24], not only in software engineering, but also in house building [14,73]. 
When the implementation goes smoother, it takes less time, it is more predictable, and 
there are fewer bugs. 

However, for reasons that are not entirely clear to me'°, a confirmed requirements 
engineer, people seem to find haggling over requirements a royal pain. They would 
much rather move on to the coding, and they feel restless, bored, or even guilty when 
forced to spend more time on the requirements. A boss with his or her eyes focused 
on an unrealistically short deadline does not help in this respect. I would bet that Amis 
Daugulis [24], his colleagues, and bosses at Latvenergo felt the pain of not being able 

Then again, I always read the manual for an appliance or piece of hardware or software 
completely before using the appliance or piece. I return the appliance or piece for a refund if 
there is any disagreement between what the manual says and the appliance or piece does, even 
if it is in only format of the screen during the set up procedure. 
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to move on to implementation, even though in the end, they were happy that they did 
not move on to implement the first two requirements specifications, which were, in 
retrospect, wrong. 

The pain is exacerbated, and is felt even by those willing to haggle the requirements, 
because the requirements engineer must make people discover requirements by clair- 
voyance rather than by prototyping. The pain is increased even more as the backtracking 
of the waterfall model sets in, as new requirements continue to be discovered, even after 
it was thought that all requirements had been found. 

There appear to be at least two ways of carrying out RE in advance of CBS design 
and implementation, what are called in the agile software development community [1] 
“Big Modeling Up Front (BMUF)” [3] and “Initial Requirements Up Front (IRUF)” [2]. 
They differ in the ways they treat the inevitable requirements changes. 

In BMUF, the CBS developers try to create comprehensive requirement models for 
the whole system up front, and they try to specify the CBS completely before beginning its 
implementation. They try to get these models and specifications fully reviewed, validated, 
agreed to, and signed off by the customer and users. Basically, the developers try to get 
the requirements so well understood that they can be frozen, no matter how painful it 
is. However, as demonstrated in Section 4, the requirements continue to change as more 
and more is learned during implementation. To stem the tide of requirements change, the 
powers with vested interest in the freezing of the requirements create disincentives for 
changes, ranging from contractual penalties against the customer who demands changes 
to heavy bureaucracy, in the form of a change review board (CRB). For each proposed 
change, the CRB investigates the change’s impact, economic and structural. For each 
proposed change, the CRB decides whether to reject or accept the change, and if it accepts 
the change, what penalties to exact. Of course, the CRB requires full documentation of 
all requirements models and specifications and up-to-date traceability among all these 
models and specifications'^. 

Agile developers, on the other hand, expect to be gathering requirements throughout 
the entire CBS development. Thus, they say that we should “embrace change” [2]. 
We should explore the effects of a proposed change against the organizations business 
goals. If the change is worth it, do it, carrying out the required modifications, including 
restructuring. If the change isn’t worth it, don’t do it [40]. It’s that simple. 

The objective of agile processes is to carry out a CBS “development project that 

1 . focuses and delivers the essential system only, since anything more is extra cost and 
maintenance, 

2. takes into account that the content of the essential system may change during the 
course of the project because of changes in business conditions, 

3. allows the customer to frequently view working functionality, recommend changes, 
and have changes incorporated into the system as it is built, and 

4. delivers business value at the price and cost defined as appropriate by the cus- 
tomer.” [69] 

" The agile development community says that traceability is a waste of resources. The cost of 
keeping trace data up to date must be balanced against the cost of calculating the trace data 
when they are needed to track down the ripple effects of a proposed change. The community 
believes that updating is so much more frequent than tracing that the total resources spent in 
continually updating outstrips the resources spent in occasional tracing. 
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Accordingly, agile developers get the IRUF, with all the stakeholders, i.e., customers, 
users, and developers, participating actively at all times, in which as many requirements 
as possible are gathered up front from all and only stakeholders. The goals of getting 
the IRUF are [2] 

1. to identify the scope of the CBS being built, 

2. to define high-level requirements for the CBS, and 

3. to build consensus among stakeholders as to what the requirements imply. 

The IRUF session ideally is as short as a few hours, but it can stretch into days and even 
weeks in less than ideal circumstances, such as not all stakeholders being in one place, 
or particularly tricky requirements. Then come several days of modeling sessions to 
produce a full set of models of the CBS as conceived by the IRUF. These models include 
use cases, which are eminently suitable for discussions between users and developers. 

Following this modeling, the requirements are ranked by priority by all stakehold- 
ers. Business goals are taken into account during this ranking process, which typically 
requires about a day. Detailed modeling of any requirement takes place only during the 
beginning of the iteration during which it is decided to implement that requirement. 

Notice that BMUF and IRUF differ in their approaches to dealing with the relentless, 
inevitable requirements changes. BMUF tries to anticipate all of them. IRUF does not; it 
just lets them come. BMUF is considered as not having succeeded totally if it fails to find 
a major requirement. The pain of dealing with the change with BMUF is felt during the 
RE process. IRUF practitioners embrace the change and decide on the basis of business 
value whether or not to do the change. The pain of dealing with the change with IRUF 
is felt in the re-implementation necessitated by the change, e.g., in the refactoring that 
can be necessary. See Section 6.4 for details about refactoring pain. Ultimately, neither 
approach can prevent a new requirement from appearing. 

6.4 Extreme Programming 

Extreme Programming (XP) [6] argues that the preplanning that is the cornerstone of 
each the various disciplined programming methods, such as the Waterfall model, doc- 
umentation, requirements engineering, is a waste of time. This preplanning is a waste 
of time, because most likely, its results will be thrown out as new requirements are dis- 
covered. XP consists in simply building to the requirements that are understood at the 
time that programming commences. However, the requirements are given, not with a 
specification but with executable test cases. Unfortunately, these test cases are not al- 
ways written because of the pain of writing test cases in general and in particular before 
it known what the code is supposed to do [58]. During this programming, a number of 
proven, minimum pain, and lightweight methods are applied to insure that the code that 
is produced meets the requirements and does so reliably. The methods include continual 
inspection, continual testing, and pair programming. Thus, the simplest architecture that 
is sufficient to deal with all the known requirements is used without too much consid- 
eration of possible changes in the future and making the architecture flexible enough 
to handle these changes. It is felt that too much consideration of the future is a waste, 
because the future requirements for which it plans for may never materialize and an 
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architecture based on these future requirements may be wrong for the requirements that 
do come up in the future. 

What happens when a requirement comes along that does not fit in the existing 
architecture? XP says that the software should be refactored. Refactoring consists in 
stepping back, considering the new current full set of requirements and finding a new 
simplest architecture that fits the entire set. The code that has been written should be 
restructured to fit the new architecture, as if it were written with the new architecture 
from scratch. Doing so may require throwing code out and writing new code to do things 
that were already implemented. XP’s rules say that refactoring should be done often. 
Because the code’s structure is continually restructured to match its current needs, one 
avoids having to insert code that does not match the architecture. One avoids having 
to search widely for the code that affects and is affected by the changes. Thus, at all 
times, one is using a well-structured modularization that hides information well and that 
is suited to be modified without damaging the architecture. Thus, the B-L upswing is 
delayed and moderated. 

However, refactoring, itself, is painful [28]. It means stopping the development pro- 
cess long enough to consider the full set of requirements and to design a new architecture. 
Furthermore, it may mean throwing out perfectly good code whose only fault is that it 
no longer matches the architecture, something that is very painful to the authors^^ of 
the code that is changed. Consequently, in the rush to get the next release out on time 
or early, refactoring is postponed and postponed, frequently to the point that it gets 
harder and harder. Also, the programmers realize that the new architecture obtained in 
any refactoring will prove to be wrong for some future new requirements. Ironically, the 
rationale for doing XP and not another method, is used as an excuse for not following a 
key step of extreme programming. 

Indeed, Elssamadisy and Schalliol report on an attempt to apply a modified XP 
approach to a software development project that was larger than any previous project 
to which they had applied XP, with great success. They use the term “bad smells” to 
describe symptoms of poor practice that can derail XP from its usual swift track [28]. 
Interestingly, each of these bad smells has the look, feel, and odor of an inevitable pain. 

1 . In XP, to ensure that all customer requirements are met, a customer representative has 
to be present or at least available at all times and he or she must participate in test case 
construction. The test cases, of course, are written to test that the software meets 
the requirements. Elssamadisy and Schalliol report that over time, the customer 
representatives began to “refrain from that ‘toil’” and began to rely on the test cases 
written by the developers. Consequently, the test cases ceased to be an accurate 
indication of the customer’s requirements, and in the end, the product failed to meet 
the customer’s requirements even though it was running the test cases perfectly. It 
appears to me that participation in the frequent test case construction was a pain to 
the customer that was caused by the relentless march of new requirements. 

2. XP insists on the writing of test cases first and on delivery of running programs at the 
ends of frequent development iterations in an attempt to avoid the well-known horror 
of hard-and-slow-to-fix bug-ridden code that greets many software development 
teams at delivery time. However, as a deadline for an iteration approaches, and 

Remember that it’s pair programming. 
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it is apparent that programming speed is not where it should be, managers begin 
to excuse developers from having to write test cases; developers refrain from just 
barely necessary refactorings; testers cut back on the thoroughness of test cases; and 
developers fail to follow GUI standards and to write documentation, all in the name 
of sticking to the iteration schedule. Speed is maintained, but at the cost of buggy 
code. It appears to me that all curtailed activities were painful in XP, just as they are 
in other methods. 

3. Elssamadisy and Schalliol report that there was a routine of doing a particular 
function, called unbooking and rebooking of a lease (URL). The first version of 
the routine did URL in the only way that was required by the first story. As a new 
story required a different specific case of URL, the required code was patched in 
to the routine as a special case. With each such new specific case of URL, the 
code became patchier and patchier; it became more and more apparent that a more 
and more painful refactoring was needed so that each specific case of URL is a 
specialization of a more generic, abstract URL. Elssamadisy and Schalliol 
were the ones who got stuck with fixing the problem. Also, because one of 
them is a big whiner, he kept complaining that “we knew this all along — 
something really stank for iterations and now I’m stuck with fixing it.” The 
sad truth is that he was right. Every developer after the initial implemen- 
tation knew that the code needed to be refactored, but for one reason or 
another ..., they never made the refactoring. 

This type of smell has no easy solution. The large refactoring had to be 
made because the inertia of the bad design was getting too high (footnote: 
Look ahead design would have been useful here also.) By taking the easy 
road from the beginning and completely ignoring the signs, we coded our- 
selves into a corner. So the moral of the story is this: when you find yourself 
making a large refactoring, stop and realize that it is probably because that 
[sic] you have skipped many smaller refactorings [28]. 

Is this ever a description of pain? It comes in a method which has been carefully designed 
to avoid many painful activities that programmers dislike. 

The claim by agile developers is that the requirements to be addressed in the first 
iterations are those with the biggest business values. Any other requirements to be con- 
sidered later are less important, and are even less likely to survive as originally conceived 
or even at all, due to the relentless change of requirements. Thus, refactoring becomes 
less and less important with each iteration. 

However, this claim presupposes that the initial set of requirements, the IRUF, is so 
comprehensive that no new important requirements, forcing a major, painful refactoring, 
will ever be discovered. It’s hard for me to imagine, and it runs counter to my experience 
that, any requirements modeling that is not the result of BMUF be so successful so as to 
effectively make refactoring completely unnecessary. Certainly, even if BMUF is done, 
it’s hard not to ever need refactoring. Thus in the end, the potential for pain is there. 

6.5 Program Generation and Domain-Specific Approaches 

One approach to simplifying programming is to use a program generator to write a com- 
plete program from a declarative specification of the program. For example, one can use 
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a compiler-compiler to write most of a compiler from some syntax and semantic spec- 
ifications for the language being compiled. These program generators do significantly 
simplify the process of writing a complete program. However, program generators are 
generally for application domains that are well enough understood that major require- 
ment surprises that force refactoring of the system’s archtecture, are unlikely. In more 
understood domains, programs are really more manufactured than they are programmed. 
In less understood domains, domain-specific approaches provide enough structure, a sta- 
ble architecture that the domain has become a true engineering discipline, like aircraft, 
automobile, and bridge engineering. In these domains, each new instance is a perturba- 
tion of all previous instance. There are surprises during construction, and signihcant ones 
too, but these surprises are still rare enough to force a wholesale change the architecture 
of the system. 

However, even program generators are not without pain. I recall that my third major 
software development project, for a summer job, was to develop a set of report programs 
operating on a single employee database. All the programs in the set were to be generated 
by RPG, the old Report Program Generator. To produce any program in the set, I specified 
the input data it needed in the database and the format and formulae for the output data, 
called the report. RPG would read this specification and write a program in assembly 
language which then had to be assembled. 1 was glad that 1 did not have to modify the 
generated program, which looked nothing like what a human being would write. To 
change a program, all I had to do was change its specihcation and to submit the new 
specification to RPG, which generated the new program. What could be simpler? 

Nevertheless, after a while, after the number of related programs grew to a number, 
n, about 10, each change of data format, each new field, each deleted field, etc. became 
a nightmare as the ripple effects reverberated to all n programs. I felt like 1 was skiing 
ahead of an avalanche even though it was a summer job in an area noted for its 90s (90°F 
and 90% humidity) weather^^. If I forgot to make a change or made the wrong change 
in one or more of the specifications, the next payroll would be a mess. 

Basically, a program generator, and for that matter all schemes for automatic pro- 
gramming [5], just move programming back to earlier in the lifecyle to a specification that 
is at a higher level than the normal program. However, even a high-level specification, 
because it must be internally consistent, gives pain when it must be modified. 

6.6 Rapid Prototyping 

Rapid prototyping [4,21] is offered as a means to identify requirements, to try out various 
ideas, to do usability testing, etc. To the extent that it succeeds, it delays and moderates 
the B-L upswing. The pain is to throw the prototype out and to start anew when imple- 
mentation starts. Often, in the face of an impending implementation deadline, instead, 
the prototype is used as a basis for the first implementation, thus ratifying poor design 
decisions that were made for expedience in putting together the prototype rapidly. The 
need to throw out the prototype and start all over with a systematic development is at 
least the need to refactor if one is following XP. When the prototype’s architecture is used 

On the other hand, in those days, computer rooms were so fiercely airconditioned that I had to 

wear my skiing sweater in the machine room. 
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for the production software, the very first production version is brittle, hard to modify, 
and prone to breaking whenever a change is made. 

6.7 Formal Methods 

There are a number of formal program development methods, each of which starts 
with a formal specification of the CBS to be built [74,22,34,37,44]. Once a formal 
specification has been written it can be subjected to verification that it meets higher- 
level formally stated requirements, such as security criteria [43]. Any code written for 
the implementation can be verified as correct with respect to the specification [41,27]. 
Sometimes implementing code can be generated directly from the specification [5]. 

Some consider the mere writing of a formal specification a pain. Some consider 
writing such a specification to be fun, but consider all the verification that needs to be 
done to be a pain. Some consider this verification to be fun. However, my experience is 
that everyone considers the work dealing with changed requirements to be a pain. The 
specification has to be changed with the same difficulties as changing code, that is, of 
finding all other parts of the specification affecting or affected by the change at hand. 

The worst of all is the necessary reverification. Since requirements are inherently 
global, formal statements about them and proofs about the formal statements are inher- 
ently global as well. Potentially every proof needs to be redone, because even though a 
theorem clearly still holds, the old proof may use changed formulae. Some have tried to 
build tools to automatically redo proofs in the face of changing specifications [56,12]. 
The pain is enough to drive one to adopt a lightweight method in which only the speci- 
fication is written and compiler-level checks are done and no verification is done [10]. 



7 Specific Methods and Techniques 

Besides models and methods for the overall process of software engineering, there 
are a large variety of specific methods and techniques each of which is for attacking 
one specific problem of software engineering. Even these small methods have their 
pains, exactly where they brush up against changes. Again, only a small sampling of 
the available methods are covered in the hope that they are a convincing, representative 
sample. 

7.1 Inspection 

The effectiveness of inspection [29] as a technique for finding errors has been docu- 
mented widely [32]. When applied to early documents, such as requirements or design 
documents, inspection helps delay and moderate the B-L upswing. However, inspection 
is a double pain. First, the documents to be inspected must be produced, and we know 
that documentation itself is a pain. Second, inspection is one of these unpopular activities 
that are the first to be scrubbed when the deadlines are looming [32]. Roger Pressman 
quotes Machiavelli in dealing with the unpopularity of inspection. 
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some maladies, as doctors say, at the beginning are easy to cure but difficult 
to recognize ... but in the course of time ... become easy to recognize but difficult 
to cure.” Indeed! But wejust don’t listen when it comes to software. Every shred 
of evidence indicates that formal technical reviews (for example, inspections) 
result in fewer production bugs, lower maintenance costs, and higher software 
success rates. Yet we’re unwilling to plan the effort required to recognize bugs 
in their early stage, even though bugs found in the field cost as much as 200 
times more to correct [64]. 

7.2 The Daily Build 

In a situation in which lots of programmers are continually modifying relatively but not 
completely independent code modules in a single CBS to fix bugs, improve performance, 
add new features, etc., a common practice is the process called the daily build [55]. 
It works best when there is tool support for version control, including commands for 
checking a module out, checking a module in, and identifying potential conflicts between 
what is checked in and what is already in. 

Each programmer gets a problem, perhaps a bug to fix, performance to improve, or a 
feature to add, and he or she plans his or her attack. When ready, he or she downloads the 
latest versions of each module that needs to be changed. He or she makes the changes, 
he or she tests and regression tests the changed modules, he or she tests and regression 
tests the whole changed system, and when he or she is satisfied that the changes will 
work, he or she checks the modules back in. 

The fun comes when each day, whatever complete collection of modules is there 
is compiled into a running version of the system and is tested and regression tested. If 
the system passes all the test, everything is fine. If not, whoever made the last change 
has to fix the problems, perhaps in consultation with other programmers, particularly 
of the modules affected by his or her changes. Consequently, the incentive is for each 
programmer to work quickly and to verify that the version of each module that is there just 
before a check in is what was checked out. If not, he or she should certainly feel compelled 
to re-implement and test his or her changes on that latest version. If the changes made by 
others are truly independent, this reimplementation is straightforward, and consists of 
folding in the independent changes identified with the help of diff. Obviously, the faster 
he or she works after checking out the modules to be changed, the less likely he or she 
will find them changed by others at checkin. Note that two programmers can work at 
cross purposes. However, if they notice that they are working on the same modules, they 
are encouraged to work together to ensure that their changes do not conflict. 

The testing, regression testing, the checking in, and possible rework are all real 
pains. Most people would just as soon dispense with them to get on to the real work, 
programming. However, in this case, the social and work costs of failing to do these 
activities is very high. Basically, the one whose checkin caused the build not to work 
correctly is the turkey of the day to be hung by his or her thumbs, and he or she has to 
spend considerable time to fix a version that has multiple programmers’ changes. 

7.3 Open Sourcing 

Open sourcing [65] is a world-wide application of the daily build, compounded from 
daily to continually. The main advantage is that the software has a world-wide legion of 
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merciless inspectors and bug fixers. Whoever sees the source of a problem is encouraged 
by the promise of fame to fix it. “Given enough eyeballs, all bugs are shallow.” The pain 
for each programmer is integrating his or her update in the face of almost continual 
change. The biggest pain is for the manager of the whole project, e.g., Linus Torvalds 
for Linux. Can you imagine what he has to go through to reconcile different fixes of 
a problem, to pick the one that he thinks fits best in a moving target. Compound this 
problem with the fact that he must deal with several problems at once. Goodness of fit 
is measured not only by how well it solves the problem but also by how consistent it 
is with all other changes that are being done. If the manager is not careful, the source 
could slide into B-L upswing oblivion very quickly. 

8 Documentation 

Almost all methods, including the general waterfall model, require programmers to 
document their decisions so that all decisions are visible to all persons working on the 
same CBS development, and even to the persons who make the decisions and later 
forget them. For example, Information Hiding requires that the interfaces and behaviors 
of the procedures and containing modules be documented so that users know what the 
modules are supposed to do without having to see the hidden code. When the documented 
information is available, the methods work as intended and the B-L upswing is both 
delayed and moderated. The kinds of documentation included are: 

1 . in the waterfall model, the requirements specification, the project plan, the design, 
the test plan, the comments, etc., 

2. in Structured Programming, the structured development itself, 

3. in Information Hiding, besides the interfaces and behaviors, for each module, the 
secret that it hides; this secret is the encapsulated design information of the mod- 
ule [39], 

4. in traceability schemes, the links between related units of the artifacts, which can 
be any other kind of documentation and the code itself [35], and 

5. in Requirements Engineering, the requirements specification, the lexicon giving 
the problem vocabulary [52], the scenarios describing how the CBS is supposed to 
be used [71,20], and sometimes a network of issues, positions, and arguments for 
capturing rationale [19]. 

A number of authors, including S. D. Hester, D. L. Parnas, and D. F. Utter [39], have 
gone so far as to advocate using the documentation that one should write anyway as a 
design medium. 

However, documentation itself is painful. It requires that people stop the analysis, 
design, or coding work that they are doing and to write their ideas down on the spot. If 
they do not stop to document, they forget the details, and if and when there is time later 
to document, a lot of the information that should have gone into the documentation has 
been forgotten. Often, there is no time to document. The shipping deadline is looming. 
So, the documentation never happens. If any of it happens, it quickly gets out of date as 
the program continues to change, and people continue to postpone recording decisions. 
Later, the programmers who must make changes have no information or poor, out-of-date 
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information about the requirements of, the architecture of, the design of, the rationale 
behind, the test plans for, and the commentary about the code. Since they do not know 
what documentation to trust, they trust none of it [26] . Therefore, they have a hard time 
finding the code and tests affecting and affected by the changes. The B-L upswing sets 
in earlier and is steeper. 

Again, the irony is that the very process that the documentation helps is the process 
that undermines the validity of the documentation. 



9 Tools and Environments 

There are a number of environments of tools that help manage CBS development by 
keeping all artifacts on-line in an editable form, by keeping relationships between the 
artifacts, by performing a variety of consistency checks and analyses, and by doing other 
mundane tasks such as running regression tests. 

The general pain of all these tools and environments is remembering to use them 
and keep their information up to date in the pressure of an impending deadline breathing 
down the developers’ necks. For example, configuration management systems [30,70,66] 
depend on programmers’ checking modules out for working on them and on program- 
mers’ checking modules back in when the programmers are finished with working on 
them. They depend on programmers’ meeting when the system suggests that they have 
to meet. When a programmer fails to check a module out, check a module back in, or 
to meet with another, the system loses control and the completeness and consistency it 
promises cannot be guaranteed any more. These requirements on the programmers are 
really not much of a pain, but programmers do occasionally forget to do one step, again 
in the rush to beat the deadline. A more complete discussion of tools and environments 
is in a technical report of the same title available at: 
http://se.uwaterloo.ca/~dberry/FTP_SITE/tech.reports/painpaper.pdf 

10 Conclusions 

Thus, it appears that there is no software engineering silver bullet*"*. All software engi- 
neering bullets, even those that contain some silver, are made mostly of lead. It is too 
hard to purify the painful lead out of the real-life software engineering bullet to leave a 
pure painless silver software engineering bullet. 

The situation with software engineering methods is not unlike that stubborn chest 
of drawers in the old slapstick movies; a shlimazel'^ pushes in one drawer and out pops 
another one, usually right smack dab on the poor shlimazel’s knees or shins. If you find 
a new method that eliminates an old method’s pain, the new method will be found to 
have its own source of pain. 

** Some have called the feeling that there is no silver bullet pessimistic. However, I view the 
feeling as optimistic, because it says that software engineering can never be automated, that it 
will always require thinking, creative, human beings. Therefore, we programmers are always 
assured of jobs! 

“Shlimazel” is Yiddish for “one who always suffers bad luck”. 
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There cannot be any significant change in programming until someone figures out 
how to deal, with a lot less pain, with the relentless change of requirements and all of 
its ripple effects. Perhaps, we have to accept that CBS development is an art and that no 
amount of systematization will make it less so. 

Software engineering is an art, no less than painting. Indeed, the first part of the titles 
of Don Knuth’s books in his series on algorithms for computer programming is The Art 
of Computer Programming [46,47,48]. The fact that software engineering is an art does 
not minimize its technical roots. A programmer must know the languages, the hardware 
platforms, the domain areas of his or her software, etc. However, what he or she does 
with them is very much a matter of art. 

Even traditional arts, e.g., painting, have technical aspects. No matter how talented 
a painter is, if he or she does not know how to work with paints, his or her paintings will 
not be good. Furthermore, as has been demonstrated by mediocre artists, knowledge of 
the techniques does not insure good quality art. 

Actually software engineering is an art just like mathematics. Both creativity and 
knowledge are required. Would mathematicians get upset if they were told that it was 
impossible to turn mathematics into a systematic engineering discipline? Would math- 
ematicians even try? 

If we know a domain well enough that architecture-changing requirement surprises 
are significantly tamed, as for compiler production these days, we can go the engineering 
route for that domain, to make building software for it as systematic as building a bridge 
or a building. However, for any new problem, where the excitement of major innovation 
is, there is no hope of avoiding relentless change as we learn about the domain, the need 
for artistry, and the pain. 

The key concept in the Capability Maturity Model (CMM) [63] is maturity. Getting 
the capability to do the recommended practices is not a real problem. The real problem 
is getting the maturity to stick to the practices despite the real pain. 

As some, including Alexander Egyed and Dino Mandrioli in private conversation, 
have observed, the psychology of computer programming [72] is coming to play here. 
Psychologically, we programmers tend to think coding as the real work and we feel 
disturbed by, pained by, and as wasting our time in, doing anything else, no matter how 
necessary the anything else is to producing quality software. 

As Les Belandy and Jack Goldberg have observed in private communication, de- 
signers and builders of large, complex systems in other engineering disciplines, e.g., of 
aircraft, bridges, buildings, nuclear power plans, etc., do not complain that there is no 
magic silver bullet for their discipline. What is the difference? Well, the engineers in the 
other disciplines know that there is no silver bullet. So why do we software engineers 
search for a silver bullet? 

The search for a software engineering silver bullet has been motivated by a belief 
that there has to be or at least there ought to be a software engineering silver bullet. After 
all, why bother looking for something that does not exist? The search is based on the 
assumption that programming can be made easy or at least systematic. 
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However, my own experience has been that programming is extremely difficult, 
of the order of difficulty of theorem proving'®, and requires much creativity as well as 
good ol’ fashioned sweat of the brow ! While certain aspects of programming, namely the 
production of code snippets that meet very well-understood requirements, i.e., the body 
of a procedure or loop not more than a few pages long, coming to grips with any other 
aspect of code, i.e., requirements, architecture, changes to requirements or architecture, 
that is, the essence, requires much creativity, blood, sweat, and tears. I am certainly not 
the only one to say so. Also Fred Brooks [17], Richard Gabriel [38], Don Knuth [49], 
and John Knight, in private communication, have said so. In particular, Knuth said. 

What were the lessons I learned from so many years of intensive work on 
the practical problem of setting type by computer? One of the most important 
lessons, perhaps, is the fact that SOFTWARE IS HARD.... From now on I 
shall have significantly greater respect for every successful software tool that I 
encounter. During the past decade 1 was surprised to learn that the writing of 
programs for TgX and for METAFONT proved to be much more difficult than 
all the other things I had done (like proving theorems or writing books). The 
creation of good software demands a significantly higher standard of accuracy 
than those other things do, and it requires a longer attention span than other 
intellectual tasks. 

One referee suggests that the focus of this paper is on the interface between the 
essence and the accidents of software. Heretofore, software engineering’s focus has 
been on one or the other. It is necessary to consider also the interface between them 
and of the feedback loop caused by that interface [5 1 ]. It is my belief that the interface 
between the essence and the accidents is of essential difficulty. 

However, a more perplexing question is how we, in computer science and software 
engineering ever go into this search for a silver bullet business, which continues to this 
very day, as indicated by the continuing claims of how method X will improve your 
programming productivity by 100% or some such large number? How did we ever get 
into this believe that programming is easy or at least systematizable? Perhaps our fields’ 
origins in Mathematics is responsible for this delusion in a perversely negative way. Some 
mathematicians, or least some that I have known, tend to look down at programming as 
not being as intellectually substantial as doing mathematics, as proving theorems, which 
is regarded as the ultimate in creativity. This belief has been the basis for denials of tenure 
to people who do only software, no matter how substantial, innovative, and creative it 
may be. This belief has been the basis for disowning of nascent software engineering 
programs. Many of us in software engineering have had to fight this shortsightedness. 
The irony is that while fighting this belief in others, we possibly have adopted it, as the 
basis for our belief that programming ought to be easy or at least systematizable. 

Perhaps now it is clear why I no longer get excited over any new language, develop- 
ment model, method, tool, or environment that is supposed to improve programming*^. 

I am reminded of a paper by Manna and Waldinger showing that programming is equivalent to 
a constructive proof of the existence of code that is partially correct with respect to input-output 
assertions [54]. 

One reviewer offered an alternative explanation, saying “It’s because you are getting old!” 
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It is clear also why I think that the most important work is that addressing requirements, 
changes, and the psychology and sociology of programming. 
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Abstract. Component based design and development of software is one 
of the most challenging issues in software engineering. In this paper, we 
adopt a somewhat simplified view of software components and discuss 
how they can be conveniently modelled in a framework that provides a 
modular approach to formal software development by means of stepwise 
refinement. In particular we take into account an observational interpre- 
tation of requirements specifications and study its impact on the defini- 
tion of the semantics of specifications of (parametrized) components. Our 
study is carried out in the context of Casl architectural specifications. 

1 Introduction 

Nowadays component based design is perceived as a key technology for devel- 
oping systems in a cost- and time effective manner. However, there is still no 
clear understanding of what is a component, and in particular of how to provide 
a formal semantics of components. Similarly, formal software development has 
received relatively little attention in the context of component based approaches. 

We focus here on a rather restrictive view of components, namely software 
components (understood as pieces of code) in contrast with system components 
(understood as self-contained computers with their own hardware and software 
interacting with each other and the environment by exchanging messages across 
linking interfaces). However, our view of (software) components is consistent with 
the best accepted definition in the software industry, see [Szy98]: a (software) 
component is a unit of composition with contractually specified interfaces and 
fully explicit context dependencies that can be deployed independently. 

There has been a great deal of work in the algebraic specification tradition on 
formalizing the intuitive idea of software development by stepwise refinement, 
including [EKMP82,GM82,Gan83,Sch87,ST88b,ST89,Sch90]; the general ideas 
go back at least to [Hoa72]. For a recent survey, see [EK99]. There are many 
issues that make this a difficult problem, and some of them are rather subtle, 
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one example being the relationship between specification structure and software 
structure. An overview that covers most of our own contributions is [ST97], with 
some more recent work addressing the problem of how to prove correctness of 
refinement steps [BH98], and the design of a convenient formalism for writing 
specifications [ABK+02,BST02a]. 

In this paper we discuss how software components can be modelled in an alge- 
braic framework providing a modular approach to formal software development 
by means of stepwise refinement. In particular we take into account an observa- 
tional interpretation of requirements specifications and study its impact on the 
definition of the semantics of specifications of (parametrized) components. Our 
study is carried out in the context of Casl architectural specifications. Archi- 
tectural specifications, for describing the modular structure of software systems, 
are probably the most novel feature of Casl. We view them here as a means 
of making complex refinement steps, by defining well-structured constructions 
to be used to build a software system from implementations of individual com- 
ponents (these also include parametrized components, acting as constructions 
providing local construction steps to be used in a more global context). 

We begin with a brief introduction to Casl basic and structured specifica- 
tions in Sect. 2. Then we present our basic view of formal software development 
by means of stepwise refinement in Sect. 3, motivating Casl architectural spec- 
ifications introduced in Sect. 4. In Sect. 5 we motivate and recall the observa- 
tional interpretation of specifications, and we study in Sect. 6 the impact of this 
observational interpretation on the semantics of specifications of parametrized 
components. An example is given in Sect. 7 to illustrate a few of the main points. 
Further work is discussed in Sect. 8. The present paper is a high-level overview 
that concentrates on presenting and justifying the concepts without dwelling on 
the technicalities, which are presented in [BST02b] and elsewhere. 

2 Casl Essentials 

A basic assumption underpinning algebraic specification and derived approaches 
to software specification and development is that programs are modelled as alge- 
bras (of some kind) with their “types” captured by algebraic signatures (again, 
adapted as appropriate) . Then specifications include axioms describing their re- 
quired properties. This leads to quite a flexible framework, which can be tuned 
as desired to cope with various programming features of interest by selecting the 
appropriate variation of algebra, signature and axiom. This flexibility has been 
formalized via the notion of institution [GB92] and related work on the theory 
of specifications and formal program development [ST88a,ST97,BH93] . 

Casl is an algebraic specification language to describe Casl models: many- 
sorted algebras with subsorts, partial and total operations, and predicates. Casl 
models are classified by Casl signatures, which give sort names (with their 
subsorting relation), partial and total operation names, and predicate names, 
together with profiles of operations and predicates. In Casl models, subsorts 
and supersorts are linked by implicit subsort embeddings required to compose 
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with each other and to be compatible with operations and predicates with the 
same names. For each signature S, the class of all Fl-models is denoted Mod{S). 

The basic level of Casl includes declarations to introduce components of sig- 
natures and axioms to give properties that characterize models of a specification. 
The logic used to write the axioms is essentially first-order logic (so, with quan- 
tification and the usual logical connectives) built over atomic formulae which in- 
clude strong and existential equalities, definedness formulae and predicate appli- 
cations, with generation constraints added as special, non-first-order sentences. 
A basic Casl specification SP amounts to a definition of a signature E and a set 
of axioms <P. It denotes the class Ib'P] C Mod{E) of b'P-models, which are those 
A-models that satisfy all the axioms in <P: Ib'P] = {A G Mod{E) \ A |= <P}. 

Apart from basic specifications as above, Casl provides ways of building 
complex specifications out of simpler ones by means of various structuring con- 
structs. These include translation, hiding, union, and both free and loose forms 
of extension. Generic specifications and their instantiations with pushout-style 
semantics [BG80,EM85] are also provided. Structured specifications built using 
these constructs can be given a compositional semantics where each specification 
SP determines a signature Sig[SP] and a class Ib'P] C Mod{Sig[SP]) of models. 

3 Program Development and Refinement 

The intended use of Casl, as of any such specification formalism, is to spec- 
ify programs. Each Casl specification should determine a class of programs 
that correctly realize the specified requirements. To fit this into the formal 
view of Casl specifications, programs must be written in a programming lan- 
guage having a semantics which assigns^ to each program its denotation as a 
Casl model. Then each program P determines a signature Sig[P] and a model 
|P] G Mod{Sig[P]). The denotation [SP] of a specification SP is a description 
of its admissible realizations: a program P is a (correct) realization of SP if 
Sig[P] = Sig[SP] and fPj G ISPj. 

In an idealized view of program development, we start with an initial loose 
requirements specification SPq and refine it step by step until we have a speci- 
fication SPiast that records all the intended design decisions: 

SPq ^ SPi SPiast 

Stepwise refinement only makes sense if the above chain of refinements guaran- 
tees that any correct realization of SPiast is also a correct realization of SP^'. for 
any P, if |P] G Ib'Pjostl then |P] G Ib'Po]. This is ensured by the definition of 
refinement. For any SP and SP' with the same signature, we define: 

SP SP' ^ Ib'P'l C ISPj 

^ This may be rather indirect, and in general involves a non-trivial abstraction step. 
It has not yet been attempted for any real programming language, but see [SM02] 
for an outline of how this could be done for Haskell. See also the pre-CASL work on 
Extended ML [KST97]. 
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The construction of a program to realize SPiast is a separate task which strongly 
depends on the target programming language. If SPiast is relatively small and 
sufficiently detailed, then achieving this task tends to be straightforward for 
clean functional programming languages and problems that are appropriately 
coded in such languages, see for instance the example in Sect. 7. If the target 
programming language is C or a similar low-level language then of course there 
is a larger gap between specification and program, largely because a lot of work 
must be devoted to mundane and complex matters like management of heap 
space that are handled automatically by more modern languages. This step is 
outside the scope of Casl, which provides means for building specifications 
only; in this sense it is not a “wide-spectrum” language [BW82]. See [AS02] 
for a more detailed discussion. Furthermore, there is no construct in Casl to 
explicitly express refinement between specifications. All this is a part of the 
meta-level, though firmly based on the formal semantics of Casl specifications. 

A more satisfactory model of refinement allows for modular decomposition 
of a given development task into several tasks by refining a specification to a 
sequence of specifications, each to be further refined independently. (Of course, 
a development may branch more than once, giving a tree structure.) 



SPi ^ ^ SPi^last 



SP'^ BR 



SP n SP n,last 



Given realizations Pi, . . . , of the specifications SPijast, ■ ■ ■ , SPnjast, we should 
be able to put them together with no extra effort to obtain a realization of SP. 
So for each such branching point we need an operation to combine arbitrary 
realizations of SPi, . . . , SPn into a realization of SP. This may be thought of 
as a linking procedure LINK br attached to the branching point BR, where for 
any Pi, . . . , P„ realizing b'Pi, . . . , SPn, LINK br{P\, . ■ . , P„) realizes SP\ 

if [Pil G I^Pi], . . . , IP„] G ISPnj then ILINKbr{Pi, ■ • ■ , P„)1 G [5P] 

Crucially, this means that whenever we want to replace a realization Pi of a 
component specification SPi with a new realization P/ (still of SPi), all we need 
to do is to “re-link” it with realizations of the other component specifications, 
with no need to modify them in any way. LINK br{Pi, ■ ■ ■ , Pi, ■ ■ ■ , Pn) is guar- 
anteed to be a correct realization of SP, just as LINK br{Pi, ■ ■ ■ ,Pi, ■ ■ ■ , Pn) 
was. In other words, the only interaction between the components happens via 
LINK br, so the components may be developed entirely independently from each 
other. 

The nature of LINK br depends on the nature of the programs considered. 
They could be for instance just “program texts” in some programming language 
like Pascal (in which case LINK br may be a simple textual operation, say, re- 
grouping the declarations and definitions provided by the component programs) 
or actual pieces of compiled code (in which case LINK br would really be linking 
in the usual sense of the word). Our preferred view is that the programming 
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language in use has reasonably powerful and flexible modularization facilities, 
such as those in Standard ML [Pau96] or Ada [Ada94] . Then Pi , . . . , P„ are 
program modules (structures in Standard ML, packages in Ada) and LINK br 
is a module expression or a generic module with formal parameters for which the 
actual modules Pi, . . . , P„ may be substituted. Note that if we later replace a 
module Pi by P' as above, “recompilation” of LINK br{Pi, ■ ■ ■ ,Pl, ■ ■ ■ ,Pn) might 
be required but in no case will it be necessary to modify the other modules. 

One might expect that BR above is just a specification-building operation 
OP (or a specification construct expressible in Casl), and branching could be 
viewed as “ordinary” refinement SP ^ OP{SP \, . . . , SPn)- Further refinement 
of OP{SP \, . . . , SPn) might then consist of separate refinements for SPi , . . . , 
SPn as above. This requires at least that OP is “monotonic” with respect to 
inclusion of model classes^. Then the following “refinement rule” is sound: 

SPx b'P'i • • • SPn'^ SP'„ 

OP{SPi, ...,SPn)'^ OP{SP\, SP'n) 

This view is indeed possible provided that the specification-building operation 
OP is constructive in the following sense: for any realizations Pi , . . . , P„ of 
SPi , . . . , SPn, we must be able to construct a realization LINK op{Pi, ■ ■ ■ , Pn) 
of OP{SPi , . . . , SPn)- In that case, OP{SPi , . . . , SPn) will be consistent when- 
ever SPi,...,SPn are. However, simple examples show that some standard 
specification-building operations (like the union of specifications) do not have 
this property. It follows that refining SP to OP{SPi , . . . , SPn), where OP is an 
arbitrary specification-building operation, does not ensure that we can provide 
a realization of SP even when given realizations of SPi , . . . , SPn- (See [HN94] 
for a different approach to this problem.) 

Another problem with the refinement step SP ^ OP{SP \, . . . , SPn) is that 
it does not explicitly indicate that subsequent refinement is to proceed by inde- 
pendently refining each of SP \, . . . , SPn, so preserving the structure imposed by 
the operation OP- The structure of the specification OP{SP \, . . . , SPn) in no 
way prescribes the structure of the final program. And this is necessarily so: while 
preserving the structure of a specification throughout the ensuing development is 
convenient when it is natural to do so, refinements that break this structure must 
also be allowed- Otherwise, at very early stages of the development process we 
would have to fix the final structure of the resulting program: any decision about 
structuring a specification would amount to a decision about the structure of the 
final program. This is hardly practical, as the aims of structuring specifications 
in the early development phases (and at the requirements engineering phase) are 
quite distinct from those of structuring final programs. 

On the other hand, at certain stages of program development we need to 
fix the structure of the system under development: the design of the modular 

^ Most of the specification constructs of Casl and other specification languages are 
indeed monotonic. The few exceptions — like imposing the requirement of freeness — 
can be viewed as operations which add “constraints” to specifications rather than as 
fully-fledged specification-building operations, cf. data constraints in Clear [BG80]. 
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structure of the system is often among the most important design decisions in 
the development process. In Casl, this is the role of architectural specifications, 
introduced in the next section. 

4 Architectural Specifications 

In Casl, an architectural specification prescribes a decomposition of the task of 
implementing a requirements specification into a number of subtasks to imple- 
ment specifications of “modular components” (called units) of the system under 
development. The units may be parametrized or not. Another essential part of 
an architectural specification is a prescription of how the units, once developed, 
are to be put together using a few simple operators. Thus, an architectural spec- 
ification may be thought of as a definition of a construction that implements a 
requirements specification in terms of a number of specified units to be developed 
subsequently. 

For the sake of readability, we present here only a very simple version of 
Casl architectural specifications, with a limited (but representative) number of 
constructs, shaped after a somewhat less simplified fragment used in [SMT+01]. 

Architectural specifications: ASP ::= arch spec Del* result T 

An architectural specification consists of a list of unit declarations followed 
by a unit result term. 

Unit declarations: Del ::= U:SP \ U: SP\-^SP2 

A unit declaration introduces a unit name with its type, which is either 
a specification or a specification of a parametrized unit, determined by a 
specification of its parameter and its result, which extends the parameter 
via a signature morphism t. 

Unit terms: T ::= U \ U[T fit a] \ T\ and T2 

A unit term is either a (non-parametrized) unit name, or a (parametrized) 
unit application with an argument that fits via a signature morphism cr, or 
an amalgamation of (non-parametrized) units. 

The semantics of this Casl fragment can be defined following the same lines 
as for full Casl, see [CoFI03,SMT+01,BST02b]. Let us just discuss here the 
semantics of specifications of parametrized units. Consider for instance the fol- 
lowing simple architectural specification: 

arch spec AS 
units Ui : SPi; 

F:SPi^SP2-, 

result F[Ui] 

To be well-formed, the specification SP\-^SP2 of the parametrized unit F 
should be such that |b'P 2 l|i C Ib'Pi] Let Si and S 2 be the respective sig- 

® Given a signature morphism t: Si — >■ S2 and a X'2-model M2 G Mod{S2), M2|t G 
Mod{Si) is the reduct of M2 w.r.t. r to a A'l-model defined in the usual way; this 
obviously extends further to classes of X'2-models. 
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natures of and SP2- To realize the specification SP\-^SP2, we should 
provide a “program fragment” AP (i.e., a parametrized program, see [Gog84]) 
that extends any realization Pi of SPi to a realization P2 of SP2, which we will 
write as AP(Pi). The basic semantic property required is that for all programs 
Pi such that |Pi] G |PPil, AP{Pi) is a program that extends Pi and realizes 
SP2 (semantically: |Ap(Pi)]|t = |Pi] and |Z\P(Pi)] G |5'P2]). This amounts 
to requiring AP to determine a partial function^ Mod{Ei) — >■? Mod{E2) 

that “preserves” its argument whenever it is defined, is defined on (at least) all 
models in [PPi],® and yields a result in |5'P2] when applied to a model in [PPi]. 
This leads to the following definitions. 

Definition 1. Given a signature morphism l: Ei — >■ E2, a local construction 
along i is a persistent partial function F\ Mod{Ei) — >■? Mod{E2) (for each 
Ai G dom{F), F{Ai)y = Ai). We write Mod(T'i— ^T'2) for the class of all 
local constructions along i. 

Definition 2. A local construction F along i.: Sig(SPi) — >■ Sig{SP2) is strictly 
correct w.r.t. SPi and SP2 if for all models Ai G |PPi], Ai G dom{F) and 
F{Ai) G |PP2]- We write [PPi— ^5'P2] for the class of all local constructions 
along l that are strictly correct w.r.t. SPi and SP2. 

The class [PPi— ^5'P2] is empty if there is some model of SPi that cannot 
be extended to a model of SP2', then we say that SPi~^SP2 is inconsistent. 

The crucial idea here is that while programs (closed software components) are 
represented as Casl models, parametrized programs (generic software compo- 
nents) are represented as persistent partial functions mapping models to models. 

Instantiation of such generic modules is then simply function application. 
This may be further complicated in Casl by cutting the argument out of a larger 
“global” context via some fitting morphism, and putting the result back into that 
context. (Hence the terminology “local construction”.) The latter involves the 
amalgamation construct, which puts together models (non-parametrized units) 
sharing common parts, as discussed in detail in [SMT+01]. 

Note that in the architectural specification AS above, although F is generic 
it is only instantiated once. Genericity is used here merely to separate the task 
of implementing SPi from the task of implementing the rest of SP2. This may 
be stressed by making the generic unit anonymous, and treating Ui as an import 
for the unit that implements SP2. In Casl, this is written as follows: 

arch spec AS' 
units Ui : SP 1] 

U 2 : SP 2 given Ur, 
result U2 

Semantically, this is essentially equivalent to AS except that the generic unit 
remains anonymous and there is an explicit name for the result. 

As in Casl, X — >■? Y denotes the set of partial functions from X to Y . 

® Intuitively, AP{P\) is “statically” well-formed as soon as Pi has the right signature, 
but needs to be defined only for arguments that realize SP\. 
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5 Observational Equivalence 

So far, we have followed the usual interpretation for basic specifications given 
as sets of axioms over some signature, which is to require models of such a 
basic specification to satisfy all its axioms. However, in many practical examples 
this turns out to be overly restrictive. The point is that only a subset of the 
sorts in the signature of a specification are typically intended to be directly 
observable — the others are treated as internal, with properties of their elements 
made visible only via observations: terms producing a result of an observable 
sort, and predicates. Often there are models that do not satisfy the axioms 
“literally” but in which all observations nevertheless deliver the required results. 
This calls for a relaxation of the interpretation of specifications, as advocated in 
numerous “observational” or “behavioural” approaches, going back at least to 
[GGM76,Rei81]. Two approaches are possible: 

— introduce an “internal” observational indistinguishability relation between 
elements in the carrier of each model, and re-interpret equality in the axioms 
as indistinguishability; or 

— introduce an “external” observational equivalence relation on models over 
each signature, and re-interpret specifications by closing their class of models 
under such equivalence. 

It turns out that under some acceptable technical conditions, the two approaches 
are closely related and coincide for most basic specifications [BHW95,BT96]. We 
follow the second approach here. 

From now on, for the sake of simplicity, we will assume that the set of ob- 
servable sorts is empty and so predicates are the only observations. Note that 
this is not really a restriction, since one can always treat a sort as observable by 
introducing an “equality predicate” on it. 

Definition 3. Consider a signature U. A correspondence between two S-models 
A, B, written p: A cxi is a relation p Q\A\x \B\ that is closed under the oper- 
ations^ and preserves and reflects the predicates^. Two models A,Bg Mod{B) 
are observationally equivalent, written A = B, if there exists a correspondence 
between them. 

This formulation is due to [Sch87] (cf. “simulations” in [Mil71] and “weak ho- 
momorphisms” in [Gin68]) and is equivalent to other standard ways of defining 
observational equivalence between algebras, where a special role is played by 
observable equalities, i.e., equalities between terms of observable sorts. 

® That is, for /: Si X . . . X s in S, ai € |A|sj,...,a„ G |d.|s„ and hi G 

\B\s,,. . . ,h„ G |B|s„, if (ffli.fei) e Psi, . . . , (on, 6n) e then /A(ai, . . . , a„) is de- 
fined iff /s(&i , . . . ,bn) G Ps is defined, and then (/A(ai, . . . ,a„), /s(6i, . . . , 6„)) G Pa. 
That is, for p: Si x ... x s„ in S, oi G | A|si ,..., On G |H|s„ and bi G \B\b,, . . . ,b„ G 
|B|s„, if (oi, 6i) G psi, . . . , (on, b„) G Ps„ then pa(oi, . . ■ , o„) <S=i> ps(&i, . . . , b„). 
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For any specification SP with Sig{SP) = S, we define its observational in- 
terpretation by abstracting from the standard interpretation as follows: 

Abs={SP) = {Ag Mod{S) \ A = B iov some B € |5P]}. 

6 Observational Interpretation 
of Architectural Specifications 

The observational interpretation of specifications sketched in the previous sec- 
tion leads to a more liberal notion of refinement of specifications. Given two 
specifications SP and SP' with the same signature, we define: 

SP SP' ^ |5'P'] C Abs={SP) 

This observational refinement concept means that now we consider that a 
program P is a correct realization of a specification SP if it determines a Sig(SP)- 
model which is observationally equivalent to an b'P-model, thus relaxing the 
requirements spelled out in Sect. 3. 

The crucial issue is now to understand how to re-interpret the semantics of 
architectural specifications to take account of the observational interpretation of 
specifications. Surprisingly enough, there is not much to change in the semantics 
of architectural specifications, the essential modifications to be made concerning 
only the semantics of specifications of parametrized units. 

The key insight is that we should require local constructions to satisfy a 
“stability” property, see [Sch87]. 

Definition 4. A local construction F along l: Si — >■ S 2 is stable if it preserves 
observational equivalence of models, i.e., for any Si-models A, B such that A = 
B, if A G dom{F) then B G dom(F) and F{A) = F{B). 

While stability seems to be an obvious requirement to be imposed on local 
constructions, it turns out that it is not quite strong enough for our purposes. 
The reason is that when applying a local construction, the argument may be 
“cut out” of a larger global context where more observations are available. To 
restrict attention to conditions that will be both strong enough and essentially 
local to the local constructions involved, we define local stability as follows. 

Definition 5. A local construction F along i.: Si — >■ S 2 is locally stable if for 
any Si-models A, B and correspondence pi: Atxi B, A G dom{F) if and only if 
B G dom{F) and moreover, if this is the case then there exists a correspondence 
P 2 '-F{A) ixi P(P) that extends p\ (i.e., p 2 |i, = Pi)- 

Obviously, local stability implies stability. However, it also implies that using 
the local construction in a global context as suggested above yields a stable 
construction at the global level as well. 

We now have the necessary ingredients to provide a re-interpretation of spec- 
ifications of parametrized units. 
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Definition 6. A local construction F along t: Sig{SP\) — >■ Sig{SP 2 ) is observa- 
tionally correct w.r.t. SP\ and SP 2 if for every model A\ G |5'Pi], A\ G dom{F) 
and there exists a model A 2 G |5P2l ond correspondence P 2 - A 2 cxi i^(Ai) such 
that p 2 |t is the identity. We write Modic{SP\-^SP 2 ) for the class of all locally 
stable constructions along l that are observationally correct w.r.t. SP\ and SP 2 . 

This implies that A 2 = F{Ai) and A 2 |t = A\, which is in general stronger 
than F{Ai) G Abs={SP 2 ). It follows that if F G Modic{SP\-^SP 2 ) then there 
is some F' G |5'Pi— ^5'P2l such that dom(F') = dom{F) and for each Ai G 
ISPil F'(Ai) = F{Ai). But in general [5'Pi^5'P2l 2 ModUSPi^SP 2 ), 
as strictly correct local constructions need not be stable. Moreover, it may hap- 
pen that there are no stable observationally correct constructions, even if there 
are strictly correct ones: that is, we may have Modic{SPi~^SP 2 ) = 0 even if 
|5'Pi— ^5'P2] 0- For a more detailed treatment of stability and of observa- 

tional interpretation of architectural specifications, see [BST02b]. 

The conclusion here is that now parametrized program modules, i.e., generic 
software components, are modelled as persistent locally stable partial functions. 
It is important to understand that stable constructions are those that respect 
modularity in the software construction process. That is, such constructions can 
use the ingredients provided by their parameters, but they cannot take advantage 
of their particular internal properties. Thus, (local) stability is a directive for 
language design, rather than a condition to be checked on a case-by-case basis: 
in a language with good modularization facilities, all constructions that one can 
code should be locally stable. 



7 Example 

The following example illustrates some of the points in the previous sections. 
The notation of Casl is hopefully understandable without further explanation; 
otherwise see [ABK+02]. 

We start with a simple specification of sets of strings. 

spec String = sort String . . . 
spec StringSet = String 
then sort Set 

ops empty : Set; 

add : String x Set — >■ Set 
pred present : String x Set 
\f s, s' : String, t : Set 

• -<present{s, empty) 

• present{s, add{s, t)) 

• s ^ s' {present{s,put{s' ,f)) 4=^ present{s,t)) 

We now refine this specification to introduce the idea of using a hash table 
implementation of sets. 
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spec Int = sort Int . . . 
spec Elem = sort Elem 
spec Array [Elem] = Elem and Int 
then sort Array\Elem] 

ops empty : Array[Elem\; 

put : Int X Elem x Array[Elem] — >■ Array[Elem]] 
get : Int x Array[Elem] — >■? Elem 
pred used : Int x Array[Elem] 
y i,j : Int; e, e! : Elem; a : Array[Elem] 

• * J put{i, e', put{j, e, a)) = put{j, e, put{i, e', o)) 

• put{i, e', put{i, e, a)) = put{i, e', a) 

• ~'used{i, empty) 

• used{i,put{i,e,a)) 

• i ^ j { used{i,put{j,e,a)) used{i,a) ) 

• get{i,put{i,e,a)) = e 
spec Elem_Key = Elem and Int 

then op hash : Elem — >■ Int 

spec HashTable[Elem_Key] = Elem_Key and Array[Elem] 
then ops add : Elem x Array[Elem] — >■ Array[Elem]; 

putnear : Int x Elem x Array[Elem] — >■ Array[Elem] 
preds present : Elem x Array[Elem] 

isnear : Int x Elem x Array[Elem] 

V i : Int; e : Elem; a : Array [Elem] 

• add{e,a) = putnear {hash{e),e, a) 

• -<used{i, a) putnear{i, e, a) = put{i, e, a) 

• used{i, a) A get(i, a) = e putnear{i, e, a) = a 

• used{i, a) A get{i, a) ^ e => 

putnear{i, e, a) = putnear (succ(i), e, a) 

• present (e, a) isnear {hash{e),e, a) 

• -<used{i,a) ~<isnear{i,e,a) 

• used{i, a) A get{i, a) = e isnear{i, e, a) 

• used{i, a) A get{i, a) ^ e 

(isnear{i,e,a) <1=^ isnear {succ{i),e, a)) 
spec StringKey = String and Int 
then op /las/i : String — >■ Int 
spec StringHashTable = 

HashTable[StringKey] with Array[String\ e- >• Set 
reveal String, Set, empty, add , present 

It is easy to check that StringHashTable is a refinement of StringSet. This is 
a fairly natural structure, building on a specification of arrays that is presumably 
already available, and including a generic specification of hash tables that may 
be reused in future. 

However, the structure of this specification does not prescribe the structure 
of the final implementation! For example, we may decide to adopt the structure 
given by the following architectural specification: 
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arch spec StringHashTableDesign = 
units N : Int; 

S : String; 

SK : StringKey given S,N; 

A : Elem — >• Array [Elem] given N; 

HT : StringHashTable 

given {A[SK] with Array[String] i-a Set} 
result HT reveal String, Set, empty, add, present 

The structure here differs in an essential way from the earlier one since we have 
chosen to forego genericity of hash tables, implementing them for the special 
case of strings. 

Further development might lead to a final implementation in Standard ML, 
including the following modules. The task of extracting Standard ML signatures 
(ARRAY_SIG etc.) from the corresponding Case signatures of the specifications 
given above is left for the reader. 

functor A(E : ELEM_SIG) : ARRAY_SIG = 
struct 
open E 

type array = int -> elem 

exception unused 

fun empty (i) = raise unused 

fun put(i,e,a) (j) = if i=j then e else a(j) 

fun get(i,a) = a(i) 

fun used(i,a) = (a(i) ; true) handle unused => false 
end 

structure HT : STR1NG_HASH_TABLE_S1G = 
struct 
open SK 

structure ASK = A (struct type elem=string end) ; open ASK 
type set = array 
fun putnear (i , s ,t) = 
if used(i,t) 

then if get(i,t)=s then t else putnear (i+l,s,t) 
else put(i,s,t) 

fun add(s,t) = putnear(hash(s) ,s,t) 
fun isnear(i,s,t) = 

used(i,t) andalso (get(i,t)=s orelse isnear(i+l,s,t)) 
fun present(s,t) = isnear (hash(s) , s ,t) 
end 

The functor A is strictly correct with respect to Elem and Array[Elem], and 
the structure HT satisfies the axioms of HashTable[StringKey] literally (at 
least on the reachable part, and assuming the use of extensional equality on 
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functions). The former would not hold if, for instance, we implemented arrays 
so as to store the history of updates: 

functor A>(E : ELEM_SIG) : ARRAY_SIG = 
struct 
open E 

type array = int -> elem list 
fun empty (i) = nil 

fun put(i,e,a) (j) = if i=j then e::a(j) else a(j) 
fun get(i,a) = let val e::_=a(i) in e end 
fun used(i,a) = not (null a(i)) 
end 

Then A’ is not strictly correct with respect to Elem and Array[Elem] (it vi- 
olates the axiom put{i,e' ,put{i,e,a)) = put{i,e',a)) but it is observationally 
correct. Similarly we might change the code for HT to count the number of inser- 
tions of each string. This would violate the axiom used{i, a) A get{i, a) = s 
putnear{i, s, a) = a, but again would be correct under an observational interpre- 
tation. 

The Standard ML functors above are locally stable: they respect encapsula- 
tion since they do not use any properties of their arguments other than what 
is spelled out in their parameter signatures. Indeed, it is impossible to express 
non-stable functors in Standard ML. 

Now let us try to instead directly implement the structure expressed by 
the specification StringHashTable. That structure may be captured by the 
following architectural specification: 

arch spec StringHashTableDesign' = 
units N : Int; 

A : Elem — >• Array [Elem] given TV; 

HT' : Elem_Key x Array[Elem] HashTable[Elem_Key]; 

S : String; 

SK : StringKey given S', TV; 

result HT'[SK][A[S]] reveal String, Set, empty , add, present 
Then we might try 
functor HT’ 

(structure EK : ELEM_KEY_SIG and A : ARRAY_ELEM_KEY_SIG 

sharing type EK.elem=A.elem) : HASH_TABLE_ELEM_KEY_SIG = 

struct 

open EK A 

fun putnear (i , e , a) = 
if used(i,a) 

then if get(i,a)=e then a else putnear (i+l,e, a) 
else put(i,e,a) 

fun add(e,a) = putnear (hash (e) ,e, a) 
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fun isnear(i,e,a) = 

used(i,a) andalso (get(i,a)=e orelse isnear(i+l,e,a)) 
fun present(e,a) = isnear(hash(e) ,e,a) 
end 

However, this does not define a locally stable functor, and is in fact not cor- 
rect code in Standard ML, since it requires equality on elem (in get(i,a)=e) 
which is not required by ELEM_KEY_SIG. There is no locally stable functor sat- 
isfying the required specification. So, what is a reasonable structure for the 
requirements specification, as expressed in StringHashTable, turned out to 
be inappropriate as a modular design. 

There is of course more than one way of changing the structure to make it 
appropriate; one was provided above in StringHashTableDesign. Another 
would be to require equality on Elem in Elem_Key, by introducing an equality 
predicate — this corresponds to making elem an “eqtype” in ELEM_KEY_SIG. 
One point of architectural specifications is that such change of structure is an 
important design decision that deserves to be recorded explicitly. 



8 Conclusions and Further Work 

In this paper, we have recalled how the standard and quite general view of formal 
software development by stepwise refinement can be refined to take into account 
some notion of components, leading to what is called architectural specifications 
in Case. An important outcome of this view is the interpretation of software 
components by means of local constructions. 

In a second step, we have taken into account the fact that a program need not 
be a strictly correct realization of the given requirements specification: it need 
only be observationally correct. Then we have pointed out how observational 
interpretation of specifications leads to the key — and quite natural — stability 
requirement on local constructions, and how this leads to a re-interpretation of 
software components by means of persistent locally stable partial functions. 

A challenging issue is now to understand how far the concepts developed 
for our somewhat simplified view of software components can be inspiring for 
a more general view of components, in particular for the case of system com- 
ponents implemented as communicating processes. While this is clearly beyond 
the scope of this paper, we nevertheless imagine that a promising direction of 
future research would be to look for an adequate counterpart of (local) stability 
in this more general setting. 
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Abstract. XML is the extensible mark-up language designed to de- 
scribe data on the world wide web. The syntax and semantics of a higher 
order applicative extension of XML is described here. In HOAX, the 
tag constructions </> a </ f> of standard XML documents denote the 
application of a function / to its arguments a. 

HOAX provides a natural “higher order XSLT”, that is, a higher order 
functional language which manipulates XML documents. 

The objective of HOAX is to make transformation and automatic gen- 
eration of XML documents more like declarative programming, thereby 
extending into the programming domain the same clarity and power of 
expression that has distinguished XML as a datatype language. 



1 Introduction 

Data modelling is always the first step in program development. The signature 
of the abstract data types is designed prior to the definition of their semantics 
or the operational behaviour of the program. Data modelling thus sets the basis 
for program structure. Several notations have been used for it, including UML 
and other well known formalisms. XML was defined a few years ago in order 
to facilitate precisely that task, namely the definition of deep data structures, 
together with their syntactic representation as fiat text. It is of great importance 
on the Internet, where it forms the basis of the next generation approach beyond 
HTML. Browsers now interpret XML as well as the traditional HTML. Indeed 
XML-capable browsers interpret HTML because HTML can be defined as an 
XML document type, one of an unbounded number of such types that may be 
constructed in XML. 

At present, we are performing a number of experiments to integrate into 
XML a behavioural component. In this paper, we present one experiment in this 
direction: attaching a functional semantics to XML tags allows us to give two 
interpretations to XML documents: the first, the “initial algebra” interpretation 
as a description of free data types and their instances, and a second, which 
represents the result of a manipulation done to the document. 
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The observation taken as the starting point for this article is that 

1 . Standard XML documents can be read as the applications of func- 
tions to their arguments 

where an XML tag is read as a function and the XML elements between the 
tags are read as the arguments. That is to say, 

<f>a</f> 

can be read as the application of the function / to the arguments a. 

This principle says something about the kind of functions that must be al- 
lowed. Some must take (sequences of) XML document elements as arguments 
and produce an XML document element or elements as result. There is also a 
function associated with an ordinary XML tag, and it is a data constructor ~ 
it constructs an XML tree from its XML branches. Other kinds of functions 
will construct different data from their arguments. In this article the question 
of how to add in higher order functions within the general framework of XML 
will be approached. Adding it gives rise to a “Higher Order Applicative XML”, 
HOAX. XML documents can then be subjected to any required analysis either 
in-line or by referencing them as elements within function tags from a HOAX 
document . 

XML and Functional Programming have often been associated in the litera- 
ture. Most of the related work tends to add XML support to some well-known 
FP languages, such as the HaXML [4] compiler and tools written in Haskell, the 
XMLambda [3] XML-based FP language, and the XML support [5] in Erlang. 
However, nothing is seemingly being done in the other direction - adding func- 
tional programming capabilities to XML. An exception, perhaps, may be XSLT 
itself, which recent papers (see for example [1]) claim can be considered as a full 
functional programming language, instead of not quite being part of the family 
of FP languages because of its lack of support for higher order functions. 

Is there really much point to extending XML to a full higher order func- 
tional language, rather than embedding XML in an existing FP language? The 
result will not be very human-readable, but it will be very easy for machines 
to manipulate. Such an extension to XML can improve the current usage in 
a number of ways: commonly, for example, applications are designed around a 
certain DTD or XML schema that defines the format for interchange and stor- 
age of documents in a given application domain. The application then provides 
the semantics. The documentation syntax alone cannot define all the constraints 
that should be imposed on the data or the use of it made in practice. But using 
HOAX functions to create “views” of an underlying XML document has ex- 
actly the effect of adding algebraic constraints to the otherwise free datatypes 
of XML. HOAX allows semantic constraints to be documented along with the 
syntactic constraints. 

A second area that HOAX lends support to is the conversion of XML doc- 
uments from one format to another, replacing the use of XSLT stylesheets for a 
given XML application. HOAX certainly binds the programming functionality 
closer to the programming data specification than in XSLT, but is also more 
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Doc :;= Abstract fn 
I Atomic src 
I Apply tag docs 

where fn :: Doc* — >■ Doc*, src :: String, tag :: Name, docs :: Doc* 

Fig. 1. HOAX documents are interpreted either as functions (abstractions, templates), 
or basic (XML) types, or are constructed from simpler elements by the application of 
a tag surround to its (document) parameters, as in XML. 



declarative in style, and importantly, HOAX is strongly typed, where XSLT is 
not. 

In this article, the semantics and the capabilities of HOAX will be the focus 
of attention. The functional semantics set out here is well adjusted to XML, 
because its data structures are XML documents and its data types are parsers 
of XML documents. To say that an XML document is of a certain type is to 
say that it may be parsed correctly by the parser associated with the type. 

A second idea of importance in this article is that 

2. Functions are documents that take parameters 

Document templates, in other words. This principle delimits the kind of object 
that is considered to be a function. A function is not something that rings the 
telephone in the middle of the night, for example. 

It also says that there are at least two types of documents: the everyday sort 
which can be read and written just as they are, and those which need to have 
extra information fed into them first. Their parameters are other documents too, 
since, in the context of HOAX, a third basic idea applies: 

3. Everything is a document 

In XML, it is usual to distinguish clearly between documents and the elements 
within documents. They lie in different syntactic categories in XML, but in 
HOAX that is not the case. This has no implications for XML itself; HOAX 
simply allows certain declarative constructs, which XML restricts to the distin- 
guished root document, to be bound with interior document elements too. So 
there is no distinguished root. 

The idea may be viewed as a first-class citizenship charter for documents; 
there is no discrimination about where a document may or may not be found in 
HOAX. If, as a result, HOAX allows a combination of XML elements which is 
not allowed in XML, the combination is simply “not XML”. HOAX extends 
XML, and XML documents are HOAX documents, but not necessarily vice- 
versa. That is fine, because HOAX documents eventually evaluate to XML 
documents when used in practice, just as complex numbers multiply together to 
give real numbers when used as part of a practical calculation. 

All HOAX documents are interpreted in one of the semantic categories in 
the abstract data type shown in Figure 1. This sets out the semantic domain of 
HOAX. There are three kinds of semantic entities listed there: atomic, abstract, 
and synthetic documents, respectively. The table below illustrates the three kinds 
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in the three rows, and gives in the first column their concrete syntax and in the 
second column gives their interpreted semantics, an abstract syntax. The square 
brackets . .]”) that appear in the second column are list delimiters, and the 
operator denotes concatenation of lists, “x” is a variable of list type: 



document 


example text 


interpretation 


atomic 

abstract 

synthetic 


"a" 

<^/ar name="x"> "a" x </var> 
<t> "a" "b" </t> 


Atomic "a" 

Abstract(Aa;. ([Atomic "a"]'~'a:)) 
Apply t [Atomic "a". Atomic "b"] 



The first example shows a simple document made by writing a single string. Its 
interpretation is as the atomic object Atomic "a", a record of kind Atomic, with 
a single field, a string. 

The second example shows a declaration of pending context surrounding two 
elements, one of them being the (possibly plural) context x. This is a document 
template, or function. The interpretation is as a record of kind Abstract, with a 
single field, a function Ax. ([Atomic "a"] "^x). The function is that which prefixes 
the interpretation of “a” (the first example) to a generic list x supplied as an 
argument to the function. 

The third example shows a standard XML tag written around two strings. 
This is a synthetic document. The interpretation is as a record of kind Apply, 
with two fields. The first field is the XML tag and the second field is the list of 
(interpretations of the) elements within the tag. 

One of the technical difficulties in designing the formal semantics for an 
applicative language based on XML is that many elements of the language have 
to be interpreted as lists even though they do not “look” like lists. That is 
because there is no clear distinction in XML between the way many types of list 
may be used, and the way a singleton of that type may be used. The simplest 
technical approach to this equivalence is to always promote elements to lists in 
the interpretation. That is why the second example above treats “a” as being 
interpreted as the singleton list of the interpretation for it given in the first 
example. 

On the technical side, this paper also defines a formal semantics for HOAX. 
It does so by defining types for the language which are also its parsers, or in- 
terpreters. Then the interpretation of a text is obtained by applying the type 
of the text to the text. This is a novel approach that succeeds quickly in prov- 
ing that the interpretation is unambiguous (because the parse can be shown to 
be unique) and also satisfies certain correctness criteria, importantly that the 
interpretation of a HOAX document is obtained by substituting its variable ref- 
erences by the documents they in turn reference. This means that the meaning of 
documents is independent of the context of their use, an important consideration 
for a language based around the World Wide Web. 

The HOAX syntax illustrated in the first column of the table is an extension 
of XML. That is, XML texts are also HOAX texts. Therefore HOAX texts 
look just like XML texts that have been “marked up” with additional “meta- 
annotations” -, the HOAX primitives. 
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<schema> 

<element name=" example" type="anyType"/> 

<element name=" double" type="anyXype"> 

<result type="anyType"/> 

</element> 

</ schema> 

<example> 

<def name=" double" var="x"> 

<val> X X </val> 

<double> <double> "goodbye" </double> </double> 

</def> 

</example> 

Fig. 2. A simple HOAX document, showing types, definition, and text “sections”. 



I defns 



The layout of this article is as follows. Section 2 defines the syntax of HOAX 
documents. Section 3 goes on to describe HOAX types and semantics. It is 
provable that there is only one parse of a document, i.e. that the HOAX inter- 
pretation is well-defined. It is also provable that the HOAX interpretation of 
functional application is substitution of the argument document in the places 
where it is referenced. This is a correctness result and it guarantees that docu- 
ments always mean what they are supposed to, despite the flexible nature of the 
XML paradigm in which they are expressed, and independently of their locale, 
which is important in terms of the world wide web. Section 4 provides further 
examples and discussions related to practical improvements in HOAX. 

2 Document Layouts 

A simple HOAX document consists of the following sections: 

1. a header section stating the types of the HOAX function tags defined in the 
rest of the document; 

2. a section giving the applicative code associated with those function tags; 

3. a section of XML-like text in which functions are applied to their arguments 
via tags and document references, resulting notionally in a transformed text. 

This picture is not complete, because both type definitions and function def- 
initions as used in HOAX may have local scope instead of global, but it is 
a useful first approximation. In this section, the concrete grammar of HOAX 
grammatical elements is discussed. 

Figure 2 shows an example of a complete HOAX document. It consists of a 
set of type headers, followed by a function definition, followed by a text area in 
which the function is applied. The XML type representing the document (the 
“root” element) is example. It is constructed by <example> tags surrounding a 
sequence of arbitrary XML elements. Its type declaration is found within the 
XML <schema> tags just above the point of use. 
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In the example, the whole document is read by generating the text contents 
within the <example> tags by the application of the <double> function tags 
twice to the string "goodbye" (XML type string). 

Note that the type of the double function is declared via a HOAX schema 
pattern, which is an extension of the XML type declaration schema. It differs 
from an ordinary XML schema in having one extra sub-element, <result>, bind- 
ing a type (and optionally a maximum repeat number). It is the type returned 
by the function. The types of the arguments to the function are still given by 
the ordinary XML “type” attribute of the HOAX element. 

The body of the function shows that it takes the argument sequence and 
duplicates it. The HOAX document shown applies the function twice. Therefore 
it is equivalent to the simple XML document below that mentions the word 
"goodbye" 2^ = 4 times: 

<schema> 

<element name="exEmiple" type="anyType"/> 

</schema> 

<example> 

"goodbye" "goodbye" "goodbye" "goodbye" 

</example> 

This valid XML content is generated on the fly by HOAX interpreters. 

In the rest of this section, the language in each of the “type”, “definition”, 
and “text” sections of a HOAX document is explained. 



2.1 Type Declaration Section 

Type declarations for function tags (which appear later in the document) are 
implemented via DTD- or XML schema-like constructs. The type of a function 
tag like double must be declared before its first use, using a format that extends 
standard XML DTD or schema declarations. If the schema format is used, an 
extra <result> sub-element declares the return type of the function. 

<element name=" double" type="anyType"> 

<result type="anyType"/> 

</elemeiit> 

Note that: 

1. arbitrary valid HOAX types are allowed, instead of just XML types; 

2. there is an extra held in the element for the return type of a function, allowing 
function types to be expressed; 

3. type declarations may precede any tag construct, and the scope of the dec- 
laration is the sequence of following text until the end of the current scope; 

4. type declarations may also declare non- functions. 
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<schema> 

<element name=/ type=ri resultType=T2/> 

<element name=a; type=ri/> 

</schema> 

<t> 

<! — 

scope in which </> . . . <//> is mentionable 
and in which x is taken to have type ri 

— > 

</t> 

where t,f ::name, Ti,T2::type 

Fig. 3. Localised schema elements are used for type declarations. 



In the case of the double example, double is a global and the type declaration 
for it covers the whole file. The general pattern of type declarations is shown in 
Figure 3, and they may be applied before any XML element. An abbreviated 
form may be used in which the attribute resultType replaces the result sub- 
element and its type attribute: 

<element name=" double" type="cUiyType" resMltrype="anyType"/> 

The following is the declaration of a non-function: 

<element name="x" type="anyType"/> 

It declares that the symbol x is to be taken as having type anyType* . 

The same symbol may be used as a tag, and may also be used “stand alone”. 
It should always be declared, however. 

Note that complex types are not allowed to be written in-line in element 
declarations in XML - only simple strings or numbers are allowed in the fields 
within tags. Instead, complex types must be written within a type construction 
in the body of the element declaration. We allow in-line forms as a convenience 
in HOAX. Thus: 

<element name=" double" type=" anyType "> 

<result> anyType </result> 

</element> 

is a strictly conforming declaration for the double function. The verbosity of 
the strict form makes it difficult to use in good conscience in the examples here. 



2.2 Definition and Text Sections 

HOAX documents generally reduce to XML documents. That is to say, the 
objective in writing them as HOAX documents is to achieve a different way of 




98 



Peter T. Breuer et al. 



obtaining an XML document. HOAX documents express transformation rules 
that may be applied to texts, and then apply them to a given text. The relation- 
ship of HOAX to XML is like the relation of complex numbers to real numbers. 
A real number (XML text) may be defined as the product of two complex num- 
bers (HOAX definitions applied to HOAX text). Likewise, an XML text may 
be the result of applying HOAX transformations to HOAX texts. 

HOAX syntax can be defined via a standard XML schema (see Figure 8). 
HOAX works like mark-up on XML documents. It introduces four special tags 
and associated grammatical constructs over and above the ordinary XML con- 
structs, the first of which is the <def> tag: 

1. <def> for binding a name to a value; 

2. <var> for expressing abstraction; 

3. <eval> for expressing the application of a function to its list of arguments; 

4. <ref> for dereferencing a variable. 

plus the ordinary XML tag mechanisms. Each of the above four constructs will 
be treated in turn. The basic idea is that definition tags bind a name to a value in 
a given expression. The other three tag constructs are supporting mechanisms. 

Definitions. The special tag <def> is used inside a document to define a new 
tag with functional semantics. It binds a name to a value in an expression, e.g. 

<def name="f" val="double"> <f> "a" "b" </f> </def> 

declares the name f to have scope from the <def name="f" val="double"> 
tag to the corresponding close tag, </def>. And the value assigned to f in the 
example is that of the already defined function double, which writes its single 
argument out twice. The above is the functional programming construct: 

let f = double in f ["a","b"] 

Normally the scope is limited to a particular element of the HOAX document. 
A special case is a definition with global scope found at the head of a document. 
Multiple simultaneous mutually recursive definitions are also allowed: 

<def namel=sum name2=map name3=count> 

<vall> . . . </vall> 

<val2> . . . </val2> 

<val3> . . . </val3> 

</def> 

and the names and the bodies must correspond in numerical count. The bodies 
may reference the names being bound. 

XML lore says that an attribute a = b inside a tag t is equivalent to an 
embedded tag <a> b </a>. When the value of the field is not an atomic type (a 
string or a number, etc.), then a tag form should be used. The generic equiva- 
lence is shown in Figure 4. The construction in the paragraph above may also 
be written <def riEmiel=sum vall=. . .name2=map val2=. . .> if the values are 
simple. 
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<a . . . b=c> d </a> 

<a . . . > <b> c </b> d </a> 

Fig. 4. Element attributes may be treated as contents via this equivalence. 

<def name=a var=fe> <val> c </val> </ def> 

<def name=a> <val> <var name=b> c </var> </val> </ def> 

Fig. 5. Function dehnitions may be shortened via this equivalence. 



Abstractions or anonymous function declarations. The special <var> tag is used 
to denote the free variable for an abstraction. The function double is here defined 
as a “lambda term” using <var> within the val element: 



<example> 

<def name=" double "> 

<val> 

<var name="x"> x x </var> 

</val> 

</def> 

</exEmiple> 

The above is equivalent to the functional programming construct: 

let double x = x x in ... 

and it means precisely to copy the list argument twice. 

It is also permitted to elide the abstraction into the definition, thus: 



<example> 

<def name=" double" var="x"> 

<val> X X </val> 

</def> 

</exEmiple> 

The general form of this elision is shown in Figure 5. 

Abstractions can always be elided (see Figure 6). The abstraction can be 
bound to a name via a definition, and then the name used instead of the ab- 
straction. 

Functional Application. Wherever an ordinary XML tags is used, then it is used 
like a constructor function. Function applications themselves look just the same 
as ordinary XML tags: 



<f> "a" "b" </f> 
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<var name=x> y </var> 

<def name=h var=x> <val> y </val> h </def> 



Fig. 6. Abstractions may be eliminated via this equivalence. 



HOAXp : := s 

I <defname="t"> <val> XS2 </val> xs'2 </def> 

I <varname="t"> xS2</’U0‘Tr'> 

I <eval iiame="t"> XS2 </ eval> \ <t> XS2 </t> 



: := <refname="t"/> I t 



where xsi :: HOAX*,a:S2 :: HOAX*gj^^j,t :: name— p, s :: string 
Fig. 7. The attributed grammar for higher order documents. 



The above means the application of function f to the sequence "a" "b". Nor- 
mally, the type of the tag <f> and the fact that it is a function tag will be 
declared in the document schema, but to allow ad-hoc uses we provide a pre- 
defined function eval which has the same effect as functional application, but 
which takes the function name as an attribute instead: 

<eval name="f"> "a" "b" </eval> 

Both type and semantics for the function tags need to be defined before first 
use. The type will normally be declared in the document DTD or schema part. 

Dereferences. The special <ref> tag can be used to dereference a variable, but 
in general it is only necessary if the variable has an exotic name, with spaces or 
reserved characters in: 

<def name=" double" var="x"> 

<val> 

<ref name="x"/> <ref name="x"/> 

</val> 

</def> 

Elisions. <eval> and <ref> can both be elided, as in the table below, when the 
identifiers they mention have previously been declared: 



undeclared 


declared 


<eval name="/"> . . . </ eval> 
<ref name="a;"/> 


</>...<//> 

X 



And as explained, an abstraction that forms the body of a definition may have 
its variable declaration absorbed into the definition tag as an attribute. 
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<?xml version="l . 0"?> 

<schema xmlns="http: //www. w3 . org/2001/XMLSchema" 
xmlns :hoax="http: //hoax . example" 
targetNamespace="http : //hoax . example"> 

<element name="hoax" type="hoax:hoax_type"/> 

<complexType name="hoax_type"> 

<choice> 

<element ref="hoax:def "/> 

<element ref="hoax: var"/> 

<element ref="hoax: eval"/> 

<element ref="hoax:ref "/> 

<! — standard top-level xml productions go here — !> 

</ choice> 

</ complexType> 

<complexType name="name_and_hoax_type"> 

<sequence> 

<element ref="hoax:hoax"/> 

</ sequence> 

<attribute name="name" type="string"/> 

</ complexType> 

<element name="def" type="hoax:def_type"/> 

<complexType name="def _type"> 

<sequence> 

<element name="val" type="hoax :name_and_hoax_type"/> 
<element ref="hoax:hoax"/> 

</ sequence> 

</ complexType> 

<element name="var" type="hoax: var_type"/> 

<complexType name="var_type" type="hoax :name_and_hoax_type"/> 
<element name="eval" type="hoax : eval_type"/> 

<complexType name= " eval_type " type= "hoax : name_and_hoax_type " /> 

<element name="ref" type="hoax:ref_type"/> 

<complexType name="ref _type"> 

<attribute name="name" type="string"/> 

</ complexType> 

</ schema> 

</xml> 



Fig. 8. HOAX texts described via an XML schema. 



The basic grammar of HOAX is expressed in Figure 7. To make it easier for 
an automatic type checker, type= . . . fields as well as nEmie= . . . fields are also 
allowed in all the tags introduced in this section, but they are not depicted in 
the grammar within the figure. 
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3 HOAX Types and Semantics 

The HOAX type system will not be described in great technical detail here. It 
suffices to understand that the types exist and that there are well-defined notions 
of equality and inclusion between types, although equality is not identity. That 
is to say there are usually at least two different ways of expressing the same 
type. The class of types contains at least 

1. the string type, string, to which all atomic strings belong; 

2. the empty type, (), or nil, to which only nothing belongs; 

3. the function space constructor ti — 1 T 2 , written T 2 (*)(ti) to conform with a C 
language -like format in DTDs (the trick is to imagine a function name where 
the middle parentheses are, so that the type declaration for function / would 
read T 2 / (ti)) and as <funType type=ri \ResultType=r 2 > in schemas; 

4. the “in sequence construct”, ti . . . t„, which represents an n-part sequence, 
written <sequence> ti . . . r„ </ sequence> in schema notation; 

5. the repeat construct r*, which represents an arbitrary finite sequence, and 
which is denoted by the maxOccurs="unbounded" modifier in schema nota- 
tions; 

6. the alternation construct ti|...|t„, which represents the union of several 
types, <alternate> T\ . . . r„ </alternate> ; 

7. the free type t of tagged data. The outfix free tag constructor <t> — </t> is 
of type T ^ t, where r is the stipulated type of the contents of the tag; 

8. type variables, which are implicitly universally quantified. 

9. the type anyType, of which every other type is a subclass. 

This contains the standard core XML type constructions. 

The typing rules (using the abbreviated type formalism above) for the HOAX 
grammar of Figure 7 is shown in Figure 9, including a final generic rule for 
typing sequences, a 6 is written where a hypothetical type statement b with 
hypotheses a is needed. The tautological rule t :: t ^ t :: t, saying how to type 
place-holders, needs no special mention, nor does the equally tautological rule 
of type loosening, t :: ti ^ t :: T 2 where T 2 is a larger type than ti. 

Each type really represents a particular ambiguous parser of HOAX texts, 
one which returns as a result of the parse a HOAX document. In this sense, a 
type is the parser and interpreter of the set of documents which it can parse and 
interpret. 

It can be proved that there is a unique parse for each HOAX document, 
given the particular parsing semantics used in HOAX. That does not mean that 
there is a unique type for each document, however. For example, any string will 
be a member both of the type string and the type string* (a sequence of 
strings) . 

The type system of Figure 9 only describes the (canonical) type of a HOAX 
document element. Each canonical type describes an interpreter for the docu- 
ment. The detail of the parsing of documents by types is set out in Figure 10. 
It can be proved that: 

Proposition 1. There is a unique valid parse of a document. 
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"s" :: string 

xsi :: Ti t :: Ti => XS2 ■■ T2 
<def name="t"> <val> xsi </val> XS2 </def> :: T2 

xsi :: Ti t :: n => XS2 ■■ T2 
<var name="t"> XS2 </var> :: T2(*)(ti) 

t :: r2(*)(n) xsi :: ri 
<eval name="t"> xsi </ eval> :: T2 

xs :: T 

<t> xs </t> :: t 

t :: T 

<ref name="t"/> :: r 

tl •• Tl ... tn ” Xn 

... Tl ... Tji 

Fig. 9. Typing rules for higher order documents. 



string r si 

= { [Atomic s] } 

T2 i <de/name="t" type=ri> <val> x </val> / </(ie/>l 

= {(At.</-)(y(At.x)) I X e (f :: n ^ n) r®! , </. G (t :: n ^T2)r/1} 

(r2(*)(n)) i <iiar’name="t" type=ri> / </ var>'^ 

= {[Abstract (At. <())] | <() G (t :: n ^ T2) i /I } 

T2 i <ei;al name="/"> r </ eval>^ 

= ( 0 X 1 [Abstract <()] G (r2(*)(n)) i/ 1 , X ^ } 

t(r) i <t> a; </t>l 

= { [Apply tx] I X e "T i*!} 

(n . . . r„) r*! ... 

= (xi'^- • "Xn I Pi" • ."Pn=a:i". . Xi e Ti ipil } 

(t :: r => r) i <T’e/name="t"/>l 

= {t} 



Fig. 10. Parse semantics for higher order documents. 



Proposition 2. Application of a function tag <h> . . . </h> is substitution of the 
tag contents a in the body H of the definition of h. I.e. The parse of 
i<de/ name="h" var="a;"> 

<val> 

H 

</ val> 

<h> a </h> 

</de/>l 

is the same as the parse of ^H[a/xf . 

As a corollary, the laws of the lambda calculus hold. 
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<switch val=x> <case var=pi> Ci </case> ...</switch> 

<def name=/i var=pi> <val> Ci </val> </i> x <//i> </def>| . . . 



Fig. 11. Equivalence for switch statements. 



4 Advanced Programming in HOAX 

Is the language described practical? For example, can a function be defined 
which counts the number of leaf elements in an XML tree? To address that 
point, certain additional features of the language need to be described, in order 
to allow for legible programming! 

The following definition of the higher order function map (which applies a 
parameter function to each of the members of a sequence) uses the <case> 
tag (see Figure 11) to match a value against several pattern/result pairs. The 
<var nEmie= . . . > syntax is extended to allow patterns in the name field. The 
type given to map by this definition is t|(*)((t2(*)(ti)) t*). 

<de/ name="map" var="#f #x.."> 

<val> 

<switch val="x"> 

<case var="#a #as.."> 

<f> a </f> <map> f as </map> 

</ case> 

</switch> 

</val> 

</def> 

There is some syntactic sugar (visible in the above) required in order to make 
patterns both visible and unambiguous. The head/tail pattern of a list is in- 
dicated by a space between the two parts in the pattern. The variables in a 
pattern are indicated by a leading hash-mark, in order to distinguish them from 
constants. The pattern which captures the tail of a list is indicated with two 
trailing dots, in order to distinguish it from a pattern which only captures a 
single member of the list. 

A subtlety in the above is that the result of the switch statement is always 
a list. All possible matches are taken. Because the pattern matches are not 
ambiguous in the above example, only a singleton results. 

As well as a literal match <t> #as. . </t> on a tag, a notation derived 

from XPath [6] is supported. In this notation, the <t> #as. . </t> pattern is 

written t/#as . . , meaning the list of elements immediately below the tag t. The 
/ means “immediately below” and // means “somewhere below”. In conjunction 
with the interpretation of ambiguity as giving a list of results, this leads to a 
shorter definition of map. The # . . is a throw-away match for a list, possibly 
empty: 
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<de/ name="map" var="#f #x.."> 

<val> 

<switch val="x"> 

<case var="#.. #a <f> a </f> </case> 

</switch> 

</val> 

</def> 

The sum of the elements of a list is defined similarly to map: 

<def name="sum" var="x"> 

<val> 

<switch val="x"> 

<case var="#a #as.."> a + <sum> as </sum> </case> 
<case var="#"> 0 </case> 

</switch> 

</val> 



With sum defined, the function count that counts the number of leaves in a 
tree can now be defined, and applied. The #/# . . #a # . . pattern catches any 
element directly below a tag, and the # pattern catches anything else, i.e. a leaf. 

<def name="count" var="x"> 

<val> 

<sum> 

<switch val="x"> 

<case var="#/#.. #a # . . "><count> a </countx/case> 

<case var="#"> 1 </case> 

</ switch> 

</sum> 

</val> 

<count> 

<hello> "there" <every> "one" </every> </hello> 

</ count> 



One practical question is how to apply the functions defined in a HOAX doc- 
ument to XML trees found in other XML documents. The solution is to make 
use of name-spaces in naming tags, a theme that cannot be explored here, but 
which is integral to XML practice. 

5 State of the Art 

In addition to those approaches already mentioned in the introduction to this 
article, namely, XMLambda, HaXML and XMerL, among the approaches which 
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add XML support to existing FP languages, XEXPR (see [2]) is a scripting 
language that uses XML as its primary syntax, making it easily embedded in 
an XML document. XEXPR was published as a W3C Note in November 2000. 
XEXPR takes a functional approach, and maps well onto the syntax of XML. 

XDuce (“transduce”, see [7]) is a typed programming language that is specif- 
ically designed for processing XML data. One can read an XML document as 
an XDuce value, extract information from it or convert it to another format, 
and write out the result value as an XML document. Since XDuce is statically 
typed, XDuce programs never yield run-time type errors and the resulting XML 
documents always conform to the specified types. 

A related approach to the separate treatment of data and transformations of 
that data is being popularised by XBRL [8] , an XML-based “business reporting” 
language. It separates financial statements and the business rules that operate 
on them. In the words of the consortium developing the standard: 

XBRL provides a consistent framework that works for all companies 
and financial statements; XBRL International sponsors the creation of 
dictionaries of tags (called ’’taxonomies”) that allow the preparation 
of financial information relative to different accounting and reporting 
standards, . . . 

and in that context HOAX applicative semantics may provide a yet more con- 
venient way of expressing the accounting rules than do imperative language 
constructs. 

6 Summary 

This article has shown how the data language XML may be adapted to support 
higher order declarative programming in a natural way. HOAX has itself been 
prototyped in the functional programming language Gofer. 

HOAX types are both the parsers and the interpreters of the language, and 
the parse of a HOAX document by its type is unique. This approach proves 
at once that its semantics is well defined. It can also be shown that the se- 
mantics given is correct, in the sense that it obeys the substitution rule of the 
lambda calculus, which means that one document may be referenced by another 
in HOAX without the reference affecting the semantics of either. Thus HOAX 
is suitable for use on the WWW, where documents will be widely scattered and 
independent. 
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Abstract. In a system-of-systems, the number of possible combinations of in- 
teractions among the systems is theoretically infinite. System “unravelings” 
have an intelligence of their own as they expose hidden connections, neutralize 
redundancies, and exploit chance circumstances for which no system engineer 
might plan. In this paper, we propose a new paradigm for system-of-systems 
design. Rather than decompose each system within the system-of-systems in a 
functional fashion, we treat the system-of-systems as a single entity that is 
comprised of abstract classes. We demonstrate how our paradigm can be used 
to both avoid the introduction of accidental complexity and control essential 
complexity by applying object-oriented concepts of decentralized control flow, 
minimal messaging between classes, implicit case analysis, and information- 
hiding mechanisms. We argue that our paradigm can aid in the creation of 
sound designs for the system-of-systems in contrast to creating a federation of 
systems through a highly coupled communication medium. 



1 Introduction! 

During the past decade, systems-of-systems have exploded into the battlespace of the 
joint and coalition warfighters. The acquisition community’s response in the U.S. 
Department of Defense to the rabid craving for more accurate information and more 
lethal functionality has been a less than stellar hobbling of various legacy systems and 
ongoing system developments through tightly coupled and lowly cohesive communi- 
cation shackles. 

While there are many issues with system-of-systems acquisitions, the first issue 
that we must address is the requirements definition and allocation issue. Just as the 
requirements issue continues to plague single-system acquisitions, the requirements 
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issue is much more complicated in the acquisition of system-of-systems. For example, 
many of the systems that comprise a system-of-systems may be legacy systems that 
operate as stand-alone capabilities in the operational world, having been developed 
with specific sets of requirements and with specific system functionality in mind. 
Additionally, just as we developed the legacy systems, we are developing new 
systems that will become members of a system-of-systems under similar conditions. 
That is, we are developing these systems as stand-alone capabilities with specific sets 
of requirements and with specific system functionality in mind. 

Now comes the desire to slam these various systems together and connect these 
systems through some communication medium in the hope of achieving greater func- 
tionality, although this tack does not necessarily result in the intended synergistic 
effect. One can identify the systems that will form the system-of-systems, and then set 
out to bend, fold, spindle, and mutilate these systems in the fevered hope of producing 
a functional composition: it is difficult to think about the system-of-systems as a 
single entity, which may explain why system developers sometimes mistakenly focus 
on modifying individual systems with little deliberation and consideration for the 
system as a whole. 



1.1 Current Approach to Developing System-of-Systems 

Our tools for reasoning about a system-of-systems typically consist of little more than 
a “sticks-and-circles” diagram. The “circles” represent the various systems that 
comprise the system-of-systems while the “sticks” are means of information transfer, 
a messaging protocol, and, perhaps, a translator box to translate the messaging format 
from one system to another. Armed with this sophomoric view of the system-of- 
systems, we attempt to analyze and describe the system-of-systems through a trivial 
picture of the various systems as connected by a convoluted labyrinth of lines. Un- 
fortunately, sticks-and-circles diagrams lack both a formal semantics and the richness 
needed to express the many dimensions of system behavior [1]. Are the circles meant 
to represent systems, subsystems, modules, classes, objects, functions, hardware, or 
some other entity? Are the sticks meant to represent data flow, triggers, synchroniza- 
tion, calls, inheritance, or something else? 

Much too often, we initiate detailed design and coding from reasoning about the 
sticks-and-circles diagrams. During the development, we add new layers of features 
and functional enhancements to the system software without clear insight into the 
organization of the system software. Inevitably, the basic organization of the software 
that seemed so reasonable at the beginning of the development process begins to 
break apart under the weight of the revisions made to the system software [2]. Sadly, 
the software development becomes another casualty to report in future studies as to 
why software developments are not successful. 

Traditionally, this methodology failed to achieve an interoperable and integrated 
system-of-systems. With each new failure, the system engineers attempted to “tighten 
up” the protocol standard; however, the system-of-systems did not achieve the desired 
degree of interoperability and integration. The end-state is a collection of systems that 
are tightly coupled with a realized protocol standard that only serves to greatly 
increase the system-of-systems software complexity. 
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As we have witnessed time and again, system software critical interactions increase 
as the complexity of highly integrated systems increases. In the complex system-of- 
systems, these possible combinations are practically limitless. System “unravelings” 
tend to have an intelligence of their own as they expose hidden connections, neutral- 
ize redundancies, and exploit chance circumstances for which no system engineer 
might plan [4]. A software fault in one module of the system may coincide with the 
software fault of an entirely different module of the system. This unforeseeable com- 
bination can cause cascading failures within the system. 

Software complexity and size are dramatically increasing in our delivered products. 
Customers are demanding more features in their systems in less time than ever before. 
Under the demands of management, software developers scurry to coding with only a 
minimal amount of planning and reasoning about software architectures and system 
requirements. As a result of this mad rush to the goal line, software developers are 
stumbling and fumbling the ball - rarely scoring a touchdown. Unfortunately, 
software developers are building software products that have about a twenty-six 
percent chance of completing on time and on budget. For Government software 
projects, developers have about an eighteen percent chance of completing their pro- 
jects on time and on budget. Moreover, the delivered products will have fewer fea- 
tures and functions than originally desired by the customer [9]. According to 
Lesishman and Cook, only two percent of the software is usable as delivered [5]. 



1.2 A New Paradigm for Developing System-of-Systems 

How do we reason about such a structure so that we have at least a modicum of 
chance to realize a functional system-of-systems? Can we extend the existing set of 
tools that we use in reasoning about a single system development to the more com- 
plex system-of-systems development? If true, can we use these tools to identify po- 
tential sources of accidental system software complexity? 

A maxim espoused in all engineering disciplines is to “keep it simple.” The best 
we can do in software engineering is to minimize “accidental complexity” and control 
“essential complexity.” Accidental complexity occurs due to a mismatch of para- 
digms, methodologies, and application tools. Essential complexity is a fact of soft- 
ware engineering in that system software is inherently complex because software 
applications are the most complex entities that humans build. As system software is 
used in ways never envisioned by the developers, operators tend to demand that ex- 
tensions be made to their system software [7]. 

While we cannot address all of the issues that negatively impact the development 
(and follow-on maintenance) of system software, we will examine the issue of re- 
quirements specification for system-of-systems. Typically, detailed system specifica- 
tions address merely the leaves of the system-decomposition tree [10]. A software 
engineer would have extreme difficulty to develop a sound and complete software 
package from only the very detailed system specifications. Indeed, software engineers 
require several layers of abstraction beginning at the top layer of abstraction down to 
the detailed system specifications. It is at the upper layers of abstraction in which 
software engineers reason about the system and make architectural and design 
decisions. 




A New Paradigm for Requirements Specification and Analysis of System-of-Systems 111 



We argue that a new paradigm needs to be adopted by the acquisition community 
in which the system-of-systems is treated as a single functional entity during require- 
ments specification and analysis. Our initial research to develop the new paradigm has 
centered on the application of object-oriented design (OOD) techniques in con- 
junction with the Unified Modeling Language (UML), which we report on in the case 
study presented in the next section. 



2 A Case Study from Missile Defense 

We begin the discussion of our proposed paradigm by first introducing a hypothetical 
missile defense system: it is a system-of-systems made of legacy systems and sys- 
tems to be constructed for providing new functionality for the composite system. 
Figure 1 is a sticks-and-circles diagram of our hypothetical system. 




Fig. 1. Components of our hypothetical missile defense system 

The greatest source of system software faults will occur in the integration of the 
various systems. With respect to our case study, the missile defense system will be a 
complex product that will contain many discrete software packages within each sys- 
tem. As a rule, these software packages will be developed independent of each other 
and programmed in many different languages. Additionally, the system will include 
legacy systems that are currently in operation. The means of integrating these ele- 
ments and legacy systems are intricate tactical data links that support the message 
transfer within the system-of-systems. 

It is difficult to both reason about requirements and analyze the system-of-systems 
by relying on the sticks-and-circles view. Although presented as a single entity, it is 
challenging to understand the affects of requirements changes and component limita- 
tions in this view. As previously mentioned, our reasoning tendency is to focus on the 
individual systems of the system-of-systems in the hope that the desired functionality 
wondrously appears. 















1 12 Dale S. Caffall and James B. Michael 



Unfortunately, magic and marvel are not tools that are abundantly available to 
system developers. Their fervent yet futile hopes for integrated systems and desired 
functionality too often fall shattered on the road of broken acquisition dreams. Frus- 
tration and antipathy are the frequent products of system-of-systems development. 

Let us propose another view of the missile defense system in which we apply UML 
and OOD techniques. We will develop a class diagram with abstract classes for the 
major components of the system-of-systems. We will reason about the class diagram 
in our attempt to develop subclasses to which we can begin to allocate requirements 
and analyze system capabilities and limitations. Additionally, we will identify mes- 
sage requirements and message flow in our attempt to reduce coupling in the system- 
of-systems by developing requirements for simplified interfaces between the compo- 
nents. Finally, we will propose a reassignment of methods to increase the cohesion of 
the components. 

The object-oriented paradigm offers a new system-of-systems requirements and 
design methodology that provides for both minimizing accidental complexity and 
controlling essential complexity through the use of decentralized control flow, mini- 
mal messaging between classes, implicit case analysis, and information-hiding 
mechanisms. 

While the hypothetical missile defense system will not be a pure object-oriented 
design, we can incorporate many of the principles of object-oriented design to de- 
crease the complexity of the artifacts produced during the development of the system- 
of-systems. We believe that software engineers of system-of-systems can use this 
object-oriented paradigm to produce a sound design for the system-of-systems rather 
than the traditional federation of systems through a highly coupled communication 
medium. 



2.1 Definition of Classes 

The first step in modeling a system-of-systems using our paradigm is to develop a 
class diagram of abstract classes. For the hypothetical missile defense system-of- 
systems, we will use the following five classes, with the corresponding class diagram 
shown in Figure 2: 

1 . Threat Missile: The Threat Missile class is the enemy missile that contains a war- 
head of mass destruction: nuclear, chemical, or high-explosive munitions. The ad- 
versary will launch the threat missile within the confines of his state. The missile 
will climb into the exo-atmospheric region that constitutes up to eighty percent of 
the missile flight. The missile will re-enter the atmosphere over our forces or de- 
fended assets at which time it will impact at its aim point. 

2. Sensor: The Sensor class is the object that detects the threat missile. Sensor is an 
abstraction of two subclasses: Infrared class and Radar class. 

3. BM/C2: The Battle Manager/Command and Control (BM/C2) class processes 
track data from the sensor. The BM/C2 monitors the threat missile, develops firing 
solutions to negate the threat missile, and directs a weapon to launch its interceptor 
with the BM/C2-provided firing solution. The BM/C2 class is an abstraction for all 
system echelons of battle management. 
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4. Weapon: The Weapon class develops firing solutions, calculates the probability 
of kill, and implements the BM/C2 authorization to engage the threat missile. 

5. Interceptor: The Interceptor class is the engagement mechanism that negates the 
threat missile. The Interceptor class is the abstraction for both directed and kinetic 
energy intercepts of the threat missile. 

The message requirements in the above class diagram are specific in comparison to 
the single, large network interface in Figure 2. One can readily determine the mes- 
saging requirements of each class, such as the Sensor class determines the attributes 
of the Threat Missile class, the BM/C2 class needs formed track data from the Sensor 
class. Weapon class waits for control data from the BM/C2 class, and Interceptor 
class waits for the interceptor release command from the Weapon class. 




Fig. 2. Class diagram of our hypothetical missile defense system-of-systems 
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2.2 Definition of Abstract Interfaces and Subclasses 

From the class diagram in Figure 2, we can begin to define abstract interfaces be- 
tween the classes. Rather than the largely unmanageable and complex network inter- 
face of the sticks-and-circles diagram, we can begin to develop specific interface 
requirements from the class-diagram approach. 

Let us add detail to the Threat Missile class as this is the point of reference for our 
missile defense system. We can develop subclasses (i.e., short-, medium-, and long- 
range threat missiles) of the Threat Missile class as depicted in Figure 3. 




Fig. 3. Subclasses of Threat Missile class^ 



In our definition of the subclasses, we have assigned attribute values. In our ex- 
ample, we have assigned fictitious data so that our example remains out of the classi- 
fied regime. These subclasses with the assigned attributes will form the basis for our 
reasoning about the missile defense system. 

The Sensor class is responsible for detecting the Threat Missile class, so let us de- 
velop subclasses that can detect the Threat Missile subclasses that we have defined. 
The subclasses for the Sensor class are depicted in Figure 4. 

By considering the subclasses of the Threat Missile class, we can design a sensor 
framework for which we can attain overlapping coverage of our sensor subclasses to 
greatly increase our opportunities for the detection of the threat missiles. We can also 



^ All attribute values listed in subclasses are fictitious and do not represent real threat missile 
data. 
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develop additional requirements to bolster our detection capability. For example, after 
considering the Threat Missile subclasses for a potential adversary, we may desire to 
increase the sensing range of the Sea-Based Sensor to extend our coverage into an 
adversary’s territory into which a Ground Sensor solution is not feasible. We can now 
levy this requirement change on the Sea-Based Sensor subclass. 




Fig. 4. Subclasses of Sensor class^ 



After we have detected a Threat Missile object, then we must develop a firing so- 
lution and engage the threat missile. As depicted in Figure 2, the BM/C2 class handles 
these functions and several other important functions. While these functions are 
related, the incorporation of these methods in a single class lessens the cohesion of the 
class. Rather than a single BM/C2 class, we might develop the BM/C2 class as an 
aggregate of several classes as shown in Figure 5. 

As depicted in Figure 2, we separated the methods for developing and realizing a 
firing solution from the BM/C2 class and assigned these methods to the Weapon 



^ The attribute values, as in Figure 3, are fictitious and do not represent real threat missile data. 
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class. These methods are similar in function so the cohesion of this class is high. This 
separation is important as the realizations of the BM/C2 and Weapon classes may 
physically reside on different hardware platforms. So, in addition to increasing the 
cohesion, we reduce the coupling by substituting more interfaces that are small and 
better defined for the larger interface required for data flow and messaging of the 
sticks-and-circles architecture depicted in Figure 2. The Weapon class and its 
associated subclasses are shown in Figure 6. 




Fig. 5. BM/C2 class as an aggregate 

Lastly, we consider the Interceptor class. Given the attributes of the Threat Missile 
class as well as potential deployment of our hypothetical missile defense system, we 
can develop the attributes and associated requirements for the Interceptor class. For 
example, the velocity of the Intermediate Range subclass of the Threat Missile class 
ranges between 1 km/sec and 2 km/sec and the distance of this same subclass ranges 
from 1000 km to 2000 km. As we consider the minimum altitude in which we must 
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negate the threat missile to ensure minimal ground effects of the resulting debris, we 
can determine minimum velocities for our three subclasses of the Interceptor class. 
These subclasses are depicted in Figure 7. 
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Fig. 7. Subclasses of Interceptor class 



2.3 Minimal Messaging between Classes 

As we reason about the classes and subclasses of our missile defense system, we can 
see that we will develop many interfaces in the realization that replaces the single, 
large network interface of the sticks-and-circles diagram of Figure 2. This is impor- 
tant to us in that we can manage a larger number of small, well-defined interfaces; 
however, the single, large network interface is much too unwieldy and complicated to 
manage effectively. We can reduce the messaging requirements of the large network 
interface to only that which is necessary for realizing the subclasses of our system-of- 
sy stems. Because the interface requirements are now manageable and known to all of 
the system developers, we have enhanced our ability to effectively integrate these 
systems into a system-of-systems. 

Additionally, by treating the missile defense components as classes and developing 
concise interfaces that implement the minimum level of information sharing among 
the classes, we can define a data structure that implements data hiding. That is, by 
reducing the message traffic among classes to only that which is necessary to com- 
plete the missile-defense missions and functions, we can prevent external programs 
from inadvertently modifying the state of a given class or injecting superfluous mes- 
sage traffic that may cause undesired system-of-systems behavior [6]. 
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By defining a data-only interface strategy, as described by Garland and Anthony 
[3], we can greatly reduce the coupling of the missile-defense components. A data- 
only interface design will result in a data-only integration realization. That is, each 
system within the missile defense system-of-systems will provide data that is suitable 
for transport and use by another system. Thus, ceteris paribus, the missile defense 
system-of-systems should exhibit the following properties: 

• More likely to work with legacy software code 

• No build-time coupling in any system 

• Missile defense systems are not required to share a common platform 

• Missile defense systems can share a database to store exchanged data 

A final benefit of realizing many small, well-defined interfaces rather than a single 
large interface will be the flexibility for incorporating future changes in a given class 
without negatively affecting the other classes. By data hiding and minimal message 
traffic, the software within a missile defense class is effectively independent in struc- 
ture and realization than the other classes. As such, an internal software change to any 
single missile defense class should not affect any other class given that the interfaces 
among the classes remain unchanged; this cause-effect relationship is discussed in [6]. 



2.4 Inheritance and Decentralized Control Flow 

As we define the class and subclass attributes, the concept of inheritance becomes 
important in that the allocation of requirements through attributes and methods en- 
sures consistency in the realization of the subclasses in our developments. Each sys- 
tem developer will know the minimum set of requirements that must be implemented 
and each developer knows what requirements the other developers will realize. 

By careful assignment of methods to each class, we can avoid the creation of the 
so-called “god class” that performs the bulk of the work within the system-of-systems 
[7]. Typically we overload the battle manager function with the vast majority of the 
work. More often than not, the battle manager software contains many dissimilar 
tasks and requires a complex messaging network. Rather than primarily exchanging 
control or triggering messages among several classes, the typical battle manager re- 
quires the continual transport of great amounts of data that results in more complex 
rules of messaging and bandwidth requirements. By employing the aforementioned 
UML and OOD techniques, we can reassign methods to other classes in which these 
methods are better suited. 

For example, consider the discriminate method listed in the BM/C2 class in 
Figure 2. This requires that the Sensor class send a great deal of data to the BM/C2 
class. Perhaps we might reason that the Sensor class should contain the discriminate 
method and send a much smaller, refined track file to the BM/C2 class for 
prosecution. This would greatly reduce the messaging requirements and greatly 
simplify the interface between the Sensor class and the BM/C2 class. 



2.5 Encapsulation 

As we reason about the classes and subclasses of the hypothetical system, we find that 
we can modify the methods to maximize the benefits of data hiding within the 
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appropriate class. In the large sticks-and-circles network of Figure 1, nearly all data is 
public by definition of the single, large interface to each system. By developing 
appropriate methods for each class, we can begin to hide data within its class. 

For example, consider the development of a firing solution for a given threat mis- 
sile. In the large sticks-and-circles network, the firing solution uses public data that is 
visible to all other systems. Because the data is public and the network connects each 
system to all other systems, it is difficult for software designers to understand the 
impact on system behavior as it is not readily apparent what system functionality is 
dependent on the public data. 

On the other hand, we can determine the data requirements for the development of 
the firing solution in the Weapon class in Figure 6, and understand that the software 
developers should hide that data within the Weapon class. While this data hiding may 
be more difficult in procedural software, the public data issue is more readily apparent 
in the class views of the system-of-systems than in the large sticks-and-circles net- 
work diagram. 



3 Integration with Other OOD Techniques 

Our approach is intended to be used to architect high-level frameworks for the sys- 
tem-of-systems. Rather than reinvent existing OOD techniques, the results of apply- 
ing our approach serve as inputs to tools that support OOD techniques for refining 
high-level frameworks into detailed structural and behavior models with formal se- 
mantics. For instance, the Assess Kill subclass of BM/C2 could be refined using the 
Real-Time Object-Oriented Modeling language (ROOM) [8]; assessing the kill in- 
volves accurately discriminating in real-time - during all phases of ballistic missile 
flight - the payload of the threat ballistic missile from other objects such as deployed 
countermeasures and debris. 



4 Conclusion 

By applying UML and OOD techniques to the system-of-systems development, we 
can glean a great deal more insight into the system-of-systems requirements definition 
and allocation issues than with the conventional sticks-and-circles diagrams so often 
used to model these large, complex systems. By developing a class diagram with 
abstract classes for the major components of the system-of-systems, we can reason 
about the class diagram in our attempt to develop subclasses to which we can begin to 
allocate requirements and analyze system capabilities and limitations. Additionally, 
we can identify message requirements and message flow in our attempt to reduce 
coupling in the system-of-systems by developing requirements for simplified inter- 
faces between the components. Finally, we can reassign methods to increase the 
cohesion of the components and we can hide data within a class to minimize the 
negative impacts of future modifications to either the system functionality or the data. 

These aforementioned benefits of applying these UML and OOD techniques can- 
not be derived from the traditional views of system-of-systems designs. While soft- 
ware designers encounter other problems in system-of-systems designs, we believe 
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that software developers can more easily reason about the system-of-systems re- 
quirements and associated allocation, thereby improving the system-of-systems ar- 
chitectures and designs by employing the techniques previously outlined in this dis- 
cussion. 
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Abstract. The World Wide Web represents a new space through which 
any kind of organization can offer services and data. The huge diffusion 
of this Internet service has led to develop a new kind of software systems, 
called Web applications. 

With the new concept of the Semantic Web the development of web 
applications should evolve including, in their implementation, the use 
of knowledge representation technologies in order to obtain all benefits 
offered by the semantics annotation of documents and data. 

We are studying the use of UML as a language for modeling organization 
ontologies as a foundation for designing Web applications which support 
organizations. 



1 Introduction 

During the last years the number of organizations which have “faced” themselves 
on the World Wide Web with their portals has incredibly increased and this 
trend probably will continue in the future. Organizations more and more rely 
upon these portals for offering services to their members or to other people. The 
large amount of information and services that these portals make available is 
accessible through the specification of URI addresses, the use of search engines, 
or following links from related arguments. 

In order to support this new usage of Web technologies, the concept of a 
Semantic Web has been introduced by Tim Berners-Lee. The goal of the Seman- 
tic Web initiative is to give to all information available on the Web a machine 
processable form, so that it can be used for several purposes, including more 
interesting results when searching some specific information, better data inte- 
gration from different sources, and the automation of organizational tasks across 
organizations. 

The World Wide Web represents a new space through which any kind of 
organization can offer services and data. The huge diffusion of this Internet ser- 
vice has led to develop a new kind of software systems, called Web applications. 
Usually these are collections of web pages and services, connected through hy- 
pertextual links, and supporting a given domain. A Web application describes 
an organization structure, and provides a set of functionalities to its users which 
are members and have specific roles in the organization. 

With the new concept of the Semantic Web the development of web appli- 
cations should evolve including, in their implementation, the use of knowledge 
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representation technologies in order to obtain all benefits offered by the seman- 
tics annotation of documents and data. In fact, a Semantic Weh application is 
intended to be a Web application, where all pages are annotated with semantics 
information, useful for describing machine processable organizational informa- 
tion. 

In order to give a machine processable form to organizational information, it 
is necessary to define domain ontologies, which are shared vocabularies suitable 
to provide say a Web page with a semantic description of its content. A do- 
main ontology maintains meta-information about information, thus it maintains 
information through the instantiation of the concepts. In order to define such 
ontologies, a set of standard technologies has to be identified. The inclusion of a 
standard semantics representation in a Web application enables the automation 
of tasks through knowledge sharing. 

For the purposes of this paper a Semantic Web application is intended to 
be a Web portal that describes an organization structure, provides a set of 
functionalities to its users, and manages and shares knowledge on organizational 
information. 

We investigate the design of a Semantic Web application from scratch, fo- 
cusing on 

— how the definition of the domain ontology affects design activities; 

— the ontology lifecycle management, and its correspondence with system evo- 
lution; 

— knowledge sharing among Web applications and automation of tasks; 

— knowledge reuse in terms of ontology evolution. 

The first issue concerns the technologies used to express a system specification 
design. The challenge here is to use the same paradigm to represent both the 
system design and the domain ontology. 

In particular, we focus on the object oriented paradigm and the set of stan- 
dard technologies it is associated to. 

More specifically, in some recent papers Cranefield [7, 8] has shown that UML 
class and object diagrams can have a direct correspondence to ontology concepts. 
We are exploiting this work in order to improve the design process of web ap- 
plications. 

Let us sketch the general method. When drawing a UML class diagram for 
a Web application we are defining de facto the elements that characterize that 
domain ontology. For instance, when we design the portal of a University, we 
have to represent concepts like professor, student, faculty, etc. Then, via the 
XML Diagram Interchange (XMI, the standard DTD for UML) [6] we can ob- 
tain a translation from a UML class diagram to a corresponding RDF schema. 
The Resource Description Framework (RDF) [2] is the technology that the World 
Wide Web Consortium proposes to describe the data contained in the Web pages 
and services, thus actually implementing a Semantic Web. The RDF is a model 
for metadata and provides interoperability between applications exchanging ma- 
chine understandable information on the Web. 
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The choice of UML for describing organization ontologies has the following 
motivations: 

— UML is a standard language for object oriented modelling; 

— it is fastly expanding its user community; 

— it is supported by several tools that facilitate the design process; 

— it is based on a graphical notation that is simpler and easier to read than 
most description logic formalisms, the usual choice to describe an ontology. 

— there exists a DTD that describes the UML metamodel 

— the XMI (XML Metadata Interchange) format for the exchanging models is 
XML-based. 

With an ontology-driven system development, several benefits can be envis- 
aged. For what concerns the ontology lifecycle management, an ontology domain 
changes or evolves when new concepts are added, or new elements replace ex- 
isting ones to the language that represents an environment. These concepts can 
be logically managed with UML diagrams. 

If the organization structure is linked to the domain ontology, they are both 
involved in each other changes. 

Ontology lifecycle management includes: 

— static aspects, reflecting the ontology model; 

— dynamic aspects, influence that these changes describing the organization 
process workflow that has direct correspondence to a Web portal. 

Directly connected to these arguments is the topic of knowledge sharing 
across organizations. With such a knowledge representation it is possible to 
integrate the domain ontology with knowledge concepts from other applications. 
This allows the communication between different sources of related environ- 
ments, and leads to the automation of tasks based on data-sharing. 

In our work we exploit a standard UML tool plus a special tool that has 
been developed by S. Cranfleld as support for a new idea for the design of web 
applications. Our research consists of methodological considerations. The VESA 
agent, presented in the section 6, is currently being implemented. 



2 The Development of Semantic Web Applications 

Our ontology-driven development method is based on: the object-oriented 
paradigm, the use of UML as modelling language, and some tools that are built 
upon some Web standards. The method suggests a guideline about the tech- 
nologies that a designer should use during the development of a Semantic Web 
application and it can be applied to any kind of process that is suitable for the 
development of Web-based applications. 

The process of building Semantic Web applications (or more general hyper- 
media) applications is not intrinsically different from the one used when building 
conventional applications. What this new generation of systems has introduced 
are the concepts of navigation and domain ontology. 
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Different approaches have been investigated for the purpose of developing 
web applications. One of the most commonly used technique is WebML [5] . It is 
a method based on the Entity- Relation (E-R) model and its features focus mainly 
on web application appearance. WebML provides an Entity- Relation based no- 
tation for the definition of data structure and it can be exhaustive in the case of 
development of simple Web applications. In order to obtain a full specification 
of a complex web application, this language should be supported by another 
one providing enough expressive constructs to fill WebML shortcomings about 
computational behavior aspects. 

Other two commonly used techniques, both based on the Object Oriented 
paradigm are: the Object-Oriented Hypermedia Design Method (OOHDM) [9], 
that was the first introducing the concept of navigational design and that has 
been a guideline for our method, and the Conallen UML extension for web appli- 
cation [14, 15] strongly based on business logic. This extension focuses, above all, 
on the implementation aspects of the development, in fact it contains concepts 
as: form, page, script, frame, client, server etc. 

3 UML and Ontologies: Related Items 

We now examine in some detail the mapping between UML elements and on- 
tologies concepts and the use of this language in the context of some projects 
that deal with ontology development. 

Given an information domain, the corresponding ontology is a schema. In 
general, a schema is a collection of classes and properties, the relations between 
them, and the constraints on their interpretation. 

The RDF, that is the general model, provides constructs to describe these 
elements. The most common formalisms used for ontology design derive from 
Knowledge Representation that is an important sub-field of Artificial Intel- 
ligence. Research in this field has produced several knowledge representation 
languages. The most relevant, as the Knowledge Interchange Format language 
(KIF), are based on semantic networks, frame systems, and first order logic. 

As underlined by Cranefield [1], unless a system that uses ontologies is con- 
structed around a specific tool based on such technologies, the use of a description 
logic formalism to represent ontologies is not so inviting. 

What he proposes is the use of a subset of the UML as ontology representation 
formalism, in order to describe ontologies in an object oriented view. 

In [17] is shown that the RDF Schema is equivalent to a subset of the class 
model in UML. The equivalence can be stated through the comparison of the 
Direct Labeled Graph (DLG) representation of the RDF Schema and UML class 
schemas. It can be shown that the RDF Schema DLG is isomorphic to a subgraph 
of the UML class schema DLG. 

Intuitively: 

— UML and RDF classes map between each other; 

— RDF Schema properties and UML attributes map between each other; 

— The RDF Schema does not support UML operations; 
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~ UML associations are expressed as RDF Schema properties; 

— Reification in RDF Schema maps to UML association names and attributes. 

The tool that Cranefield has realized is named “UML Data Binding” (UDB). 
The UDB implements the mappings from UML class diagrams to RDF schemas 
and sets of Java classes exploiting the XMI encodings of the class diagrams. 
This XML-based representation of the ontology model is the input of a set of 
stylesheet that realize the translation. 

The generated Java classes allow an application to represent knowledge about 
objects in the domain as in-memory data structures. The generated schema in 
RDF defines domain-specific concepts that an application can reference when 
serializing this knowledge using RDF (in its XML encoding). 

Another similar tool is in phase of development by the UBOT team. The 
UML Based Ontology Toolset (UBOT) [13] is a project that is part of the 
DARPA Agent Markup Language (DAML) program and is based on DAML 
ontology development. A schematization of the UBOT model is shown in figure 
1 taken from [13]. 




Fig. 1. The UBOT model from [13]. 



A DAML ontology engineer would graphically model a new ontology or ex- 
tend an existing ontology with the UML GUI. The model will be exported from 
the UML GUI in XMI format to the UML Formalization component, which 
translates the model to Slang for consistency checking in Specware. 

The engineer will correct the model based on consistency checking results. 
The model will then be exported to the UML DAML translation component. 

The UBOT has also other objectives besides the creation of DAML ontolo- 
gies. One of them is building a tool-set that supports the consistency checking of 
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ontologies. This issue is approached with formal verification and lexical seman- 
tics. Another objective concerns the annotation of pages for software agents. 

This set of tools can be used, in an ontology-driven design approach, in place 
of the UDB tool for the definition and the automatic serialization of the ontology 
schema of the application domain. 

4 Our Method Applied to a Case Study 

In this section we will sketch a method for the ontology-driven design of a Seman- 
tic Web application. This ontology-driven design method will produce a model 
that will be used to obtain the correspondent RDF specific schema expressed 
in XML format and will also be used as a conceptual model for a Web portal. 
Actually, we will take in account only a subset of the entire domain, but it can be 
a starting point from which the representation of the domain can be completed. 

To explain the method we have chosen as a case study a domain that is well 
known to all academics, namely the organizational structure of a university. 

A university is a large and complex educational and research organization. 
Terms as student, professor, exam, research, library, etc. are typical of this do- 
main. For instance, the University of Bologna (UniBO for short) is composed 
of faculties, which coordinate teaching activities, and departments, which co- 
ordinate research activities. These two structures are autonomous but strictly 
interrelated. Each faculty offers several courses and benefits of services from a 
certain number of departments. Professors are employed and work for one fac- 
ulty. They are also affiliated to a department in which they act as researchers. 
Professors can teach more that one topic within different courses, etc. 

Since UniBO is a large and complex organization the UML model which 
describes its organizational structure consists of a set of class diagrams each 
contained in a different package that underlies a specific aspect. 

At the top level there are two packages: the General and the UniBOntology 
packages. The former one contains the model of a General ontology, it has been 
defined with the aim of showing an example, and it is a UML representation 
of a subset of the “General Ontology Draft” of the Simple HTML Ontology 
Extension (SHOE) project [16]. Here, concepts that can be used also for other 
domains, completely different from the university one, are defined. The General 
ontology is extended by the UniBOntology through the use of UML specialization 
constructs that correspond to the rdf s : SubClassDf property provided by the 
RDF Schema. 

The two packages are shown in figure 2. 

In order to define an ontology for UniBO, we choose to describe the university 
structure, its hierarchy and organization, using a vocabulary that expresses its 
typical concepts and relationships. 

The elements for the UniBOntology are modelled in the UniBOntology pack- 
age. The classes that it contains form a taxonomy for the domain while relation- 
ships between them and their attributes define the properties of the taxonomy’s 
elements. 




128 



Paolo Ciancarini and Valentina Presutti 







UniBOntlogy 




General 



Fig. 2. Top level packages. 



The figure 3 shows the set of packages that the UniBOntology one contains. 
An arrow connecting two packages means that the starting package depends on 
the ending package (e.g. the ending package defines a class that the starting 
package uses). 
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Fig. 3. UniBO uml model: the UniBOntology packages. 



The University package can be seen as an abstract model of the UniBO 
organization that omits details, the People package contains the classes describ- 
ing the roles that people act within the UniBO, the Uni-Documents package 
describes the types of documents that can be created as reports of university 
people’s work, the Teaching and Research packages describe all the elements 
that contribute to perform the main activities of the UniBO. The Relations 
package contains other packages, each showing the relationships between classes 
of the various packages. 

At the end of the design process we have a set of class diagrams that describes 
the typical elements of our domain and how these elements relates to each other. 
Thus, we have a specific schema to express the entities composing the University 
of Bologna and make them publicly available on the World Wide Web. 

The result should be a model for the web portal where all the pages composing 
it will be automatically annotated with semantics information. A web resource is 
said to be annotated if it is explicitly and formally associated with information 
describing its semantic meaning. 
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The other side of the development should be the specification of a collection 
of pages and services. The Web portal system specification will evolve with 
its navigational design, interface definition and implementation. The ontology 
schema will be used to annotate the pages. They both combined together will 
give the aimed result. 

This description seems to completely separate the two models, suggesting 
the idea that the ontology serves to integrate the portal with metadata, but it 
is separately defined. This situation is realistic if we have an existing web portal 
and we want to provide it with semantics annotations. On the other side, if we 
are creating from scratch a novel Semantic Web application it is appealing the 
idea of obtaining the desired ontology schema without an increase of the design 
activity efforts. 

This can be achieved considering that the ontology model is essentially very 
similar to the conceptual model. In fact, the conceptual model can be obtained 
directly from the ontology model by simply performing a dropping of the classes 
representing concepts that are significative only for ontological purpose and that 
not correspond to any object in the final web application. For instance, consider- 
ing the Object-Oriented Hypermedia Design Method (OOHDM) [9] this selection 
can be done without any additional design efforts. It is important to notice that 
this integration can apply to any kind of process method and that extending the 
OOHDM is just an example of its possible application. 

The figure 4 shows a schematic description of the steps performed in the 
ontology-driven development process, that extends the OOHDM; some of these 
steps can be iteratively repeated. 

The activities that this method includes are: Ontology Design, Conceptual 
Design, Navigational Design, Object Model, Interface Definition, and Implemen- 
tation. 

The object model is a collection of UML object diagrams that describes an 
abstract representation of the knowledge information that will be contained in 
the specific Semantic web application we are developing. It can be constructed on 
the base of the ontology and navigational models, that together give the structure 
of the application. This abstract representation can be used to automatically 
generate a serialization format to allow web publication and transmission of the 
knowledge. 

The object model will be integrated with diagrams every time new informa- 
tion has to be added, so it can be seen as a component that evolves during the 
application life cycle. 

The ontology-driven process is based on the UML as the modeling notation 
for the design activities. We have used some tools, allowing the automatic trans- 
lation from class diagrams and objects diagrams to a correspondent serialization 
format that allows Web publication. In the context of this work we have used for 
this purpose the UDB technology [8] together with a Rational UML supporting 
tool. 

The UniBO Semantic Web application will then integrate its realization with 
the semantic annotation of its pages. This will allow, as said above, the commu- 
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Fig. 4. The ontology-driven method for developing Semantic web applications. 



nication between different sources of related environments, and the automation 
of tasks based on data-sharing. In the next section we describe two possible 
scenarios where knowledge representation features can be exploited. 



5 Two Example Scenarios 

A main goal of a Semantic Web application consists of enabling more exact 
results when a user performs a web search on its specific domain. 

Developing an ontology for managing knowledge about academic entities and 
relationships can have several benefits. For instance, suppose that an undergrad- 
uate student has to collect documents about some topic. He could use the UniBO 
portal to inquire about which are the researchers working on a particular area 
and the articles that they have written about that topic. Or he could design an 
agent to search for articles on a particular subject whose authors are member 
of a particular set of institutions. If the search is based on current search en- 
gines (not based on semantic web technologies) the answer could include a large 
number of uninteresting answers because currently engines rank each page based 
upon how many of the query terms it contains. 

When all the pages of the UniBO web portal are annotated with metadata 
describing semantics information, the result of the query could be a graph of all 
possible pathways that match the query. The figure 5 shows a possible layout 
of the result of a search about all the articles whose subject is the “Ontology 
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research area” and whose authors are members of departments belonging to 
UniBo. This example does not refer to a particular implementation for the search 
engine but just to the environment supporting the engine. For this reason, the 
syntax of the query can be different depending on the particular implementation 
of the search engine. 




Fig. 5. An example of searching result as a semantic graph. 



The nodes of the graph represent resources, and the connecting arcs represent 
properties. Each arc has a label indicating the property name it represents. All 
nodes are hypertextual links to the URL containing that resource information. 
For example, in the case of an article the URL could refer to a downloadable 
version (eg. a pdf file) or to a web page containing the article. Thus, the user 
can follow the links he finds more interesting for his purposes. 

The second example concerns the interoperability aspect of ontologies. A 
frequently realistic scenario in our case study happens when a student asks for 
a transfer from his current university to the UniBO. In this case it is necessary 
to identify which are the exams that the student has taken in the old university 
and that will be considered valid also for his career inside the UniBO. 

In a situation of ontology sharing, the ontology of the university from which 
the student comes from has a non-empty intersection with the UniBOntology. A 
possible way of addressing the validation of exams issue could be the application 
of the following rule. Each exam taken at the university of origin that has a 
corresponding one in the UniBOntology will be considered valid and will be 
stored in the new student’s profile created for the University of Bologna. The 
matching is regulated by semantics constraints defined by the two ontologies. 

The figure 6 shows an example instance of a student transfer. In this case 
the student “Pippo” has taken four exams at the University of Pisa (UniPI for 
short). By applying the rule described above it results that two of these exams 
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Fig. 6. Exams validation for a student transfer from the UniPI to the UniBO. 



can be validated at the UniBO. Thus, these two exams will be stored in a UniBO 
student profile for “Pippo” . 



6 The Development of the VESA Agent 

We are developing a software agent in order to realize the automation of the 
exams validation task presented as an example in the previous section. Our 
agent’s name is Validation Exams Software Agent (VESA) and it exploits the 
annotation of resources. 

The first issue is the identification of the environment in which the agent will 
operate, say the elements it will use and interact with. 

The figure 7 shows the input that the VESA agent needs in order to compute 
its main task and the output it produces. 

As it can be seen, it needs two elements as input: one or more ontology 
references and a set of semantic data. The ontology references allow it to find 
the definitions of the concepts that are used in the annotated resources. 

In this way it can understand those pieces of information. In the figure the 
ontology is written in OWL as well as the resource semantic annotation. This 
is only a possibility because the mechanism would be the same if we use other 
ontology languages. 

The VESA output is an XML document containing semantic annotation that 
describes the new student’s profile in the destination university database. 

The figure 8 shows, at a high level of abstraction, the whole architecture of 
the VESA environment. 
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Fig. 7. VESA inpnt-output. 




Fig. 8. A high level of abstraction for the VESA environment architecture. 



In particular, there is a user that asks for a student transfer providing the 
necessary information to activate the agent. The user can be any of these: a 
human person, a software agent, or a web service. 

An example of input data are the matriculation number of the student, the 
code of the forwarding university and code of the destination university. 

Then the agent decides if the task can be accepted by computing a validation 
operation. If it can then it uses the information it holds in order to find the 
document containing the current student’s profile. 
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If that document contains the proper semantic information then it searches 
for the ontology references he needs to understand the document and to apply 
the rules of the destination university for the student transfer. 

All the ontology references, the student’s current profile and the rules of the 
destination university are provided by the Semantic web portals that represent 
the two universities. These portals can supply these information either through 
a web service or a software agent. 



7 Conclusion and Future Works 

We have investigated the design of a Semantic Web application from scratch, 
focusing on how the definition of the domain ontology affects design activities. 
The challenge was to use the same paradigm to represent both the system de- 
sign and the domain ontology. In particular we focused on the object oriented 
paradigm and the set of standard technologies it is associated to. 

More specifically, Cranefield [7, 8] has shown that UML class diagrams and 
object diagrams have a correspondence to ontology concepts and the Object- 
Oriented Hypermedia Design Method (OOHDM) is an object-oriented-based 
technic for Web-based software systems development. 

In particular our contribution relates on the definition of a method (the 
ontology-driven design), we have investigated the correspondence between the 
Semantic web application conceptual design and the domain ontology design. 
We find that the former can be derived from the latter. Then, via the XML 
Diagram Interchange (XMI, the standard DTD for UML) [6] we can obtain a 
translation from a UML class diagram to a corresponding RDF schema and a 
set of Java classes in order to annotate the web pages composing the Web portal 
with semantics information about their content. This automatic translation was 
already possible thanks to related works. In particular, in the context of our 
research we have exploited the UDB tool [7, 8] . 

The result has been the definition of a process for the development of Se- 
mantic web applications called ontology -driven method that consists of two new 
activities concerning the ontology design and the modeling of knowledge as ob- 
ject diagrams, and the use of supporting technologies like the UDB for the se- 
mantics annotation of web pages. Actually, this approach can be applied to all 
kind of Object-Oriented development processes, in this paper the OOHDM has 
been taken as a suitable example because it contains concepts that we found 
interesting. 

The real aspect that has been underlined is that the introduction of an on- 
tology design activity in a development process does not introduce new design 
efforts, and allows to exploit knowledge representation in order to achieve the 
communication between different sources of related environments, and the au- 
tomation of tasks based on data-sharing. 

As future extension of our work, it is desirable the creation of a UML ex- 
tension for the treatment of Semantic Web concepts. An agent-based UML ex- 
tension has been already proposed to the OMG [10]. The definition of a UML 
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specific extension for ontology modeling would make it easer to handle imported 
ontology schemas and the modeling of interaction scenarios between agents and 
Semantic Web applications. Such an extension could be associated to a UDB-like 
procedure thus allowing the automatic translation from UML models to a cor- 
respondent serialization format that allows Web publication. This format could 
be based on the Web Ontology Language (OWL) [11], the candidate standard 
for representing ontology on the Web. 
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Abstract. Design of reliable distributed systems is stretching limits in terms of 
complexity since existing development techniques are usually not fully accurate 
for this type of applications. The main problem is the gap between the various 
notations used during the development process. Even if UML is a significant 
step forward, it is not fully suitable for model based development of distributed 
systems. 

We present a model based development approach based on L/P (Language for 
Prototyping) applied to distributed systems. It emphasizes the use of a model 
serving as a basis for automatic code generation; strong connections with formal 
verification techniques enforce correcteness of the system. The paper focuses on 
the description of code generation techniques. 



1 Introduction 

The fast evolution of distributed technology has led to systems stretching that stretch the 
limits of complexity and manageability [12]. A majorproblem when distributed systems 
have to be certified resides in both the design and coding phases: collected requirements 
may be incomplete, inconsistent or misunderstood, and the numerous interpretations of 
a large specification often leads to unexpected implementation and additional debug- 
ging costs. 

The problem comes from the gap between the various notations used in the soft- 
ware life cycle (natural languages, specification languages, programming languages). 
A first solution is to use a methodology that provides a coherent set of notations to 
solve this problem. The UML standard [18] represents a significant advance to system 
specification, however: 

- UML semantics is not sufficiently formally defined to enable formal verification 
unless strong restrictions and hypotheses on its use are introduced (like in [2, 5]); 

- Good code generators available for information systems are lacking for distributed 
applications since UML is not fully adapted to capture all aspects of distributed 
architectures [15]; 
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- UML relies on object orientation, that can be easealy implemented using middle- 
ware such as CORBA [17] or Ada-DSA [7] that implement distributed objects. 
However, the use of other classes of middleware (such as MPI [14]) requires the 
implementation of adaptation components to handle object oriented mechanisms. 
Similarity, implementation of an UML specification according to profiles for em- 
bedded systems such as ravenscar [4] is delicate since dynamic mechanisms are 
forbidden in such systems; 

- The behavioral semantics of UML will remain informally defined for several years 
since the 2.0 initial submission claims it essentially formalize static/structural as- 
pects [19]. It introduces OCL to define constraints precisely but only a very limited 
number of pages are dedicated to the description of unambiguous behavior of a 
system. 

Therefore, for distributed systems, UML is mostly valuable in the early stages of 
the software life cycle. When a preliminary object-oriented solution is sketch, there 
is a need for another type of description closer to implementation (e.g. that does not 
necessarily rely on object oriented middleware). This new description should enable 
both formal verification (a well accepted approach to ensure high quality in distributed 
systems) and automatic program generation (to ensure coherence between specification 
and program). 

This paper presents our proposal for a model based development approach. It em- 
phasises the use of a model that formally defines behavioral aspects of the system. This 
model is used to automatically generate the control code of a distributed application. It 
is also suitable for formal verification. 

Our methodology is presented in section 2. It relies on a notation briefly described 
in section 3. We then focus on how programs can be derived from these specifications 
in section 4. 

2 Model Based Development 

Model-based development [22] focuses on the use of a model that serves as a basis for 
two main objectives: formal verification and automatic program generation. We favor 
this approach and consider that it corresponds to an evolutionary prototyping approach 
[11]. Our proposal relies on L/P, a high-level modeling language that unambigously de- 
scribes the behavior of a distributed systems using Behavioral diagrams (automata with 
structuring facilities). Behavioral diagrams express contracts to be obeyed by compo- 
nents of a distributed system. For example, a class C may state that method M\ has 
to be executed prior to the execution of mehod M 2 . It may also state that method M 2 
cannot be executed twice. L/P also provides facilities to insert assertions like invariants 
of temporal logic formulas into the model. This information is suitable for verification 
purposes and can be used by code generators to optimize programs. 

We aim to formalize relations between system modeling, formal verification and 
code generation of distributed systems in order to provide: 

- transparent formal verification to enable its use in an industrial context without 
requiring both a heavy training and some specific skills, as outlined in [13], 
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Fig. 1. Model based development using evolutionary prototyping. 



- strong correspondence between the detailed description of a system, its proofs and 
its implementation. In other words: “what you describe is what you check and im- 
plemenf’. 

As shown in Fig. 1, we aim to plug our model based development approach into 
a “classical” requirement/analysis phase that produces an UML model. First, a refor- 
mulation of this model into L/P must be considered. Most of the work should be done 
by a tool (producing behavioral state machines from collaboration diagrams cannot be 
completely automated [9]) but designers have to add information such as the behavioral 
contracts and assertion to be verihed (e.g. “this server has to provide an answer”) that 
cannot be automatically deduced from UML diagrams. When program generation is 
used, designers also add informations used by code generators (e.g. “components af- 
fected to this host are coded in Java”). This additional information is sometimes located 
in UML tagged values supported by some CASE tools. However, such information is 
potentially non standard. 

From this central description two types of operations can be performed: 

- Formal specihcation generators produce formal specification to be verified: the 
transformation is optimized according to the property to be verified (i.e. the ap- 
propriate couple <formal method, used technique> is selected). 

- Program generators produce source files to be compiled and integrated in the target 
execution environment. These generators have to deal with code generation tech- 
niques (how to translate the L/P semantics into a given language) but also with 
configuration and deployment of the system on top of the target architecture. 

Model-based development, similarly to model driven architecture [20], is a devel- 
opment strategy promoting the use of various techniques: modeling (as precise as pos- 
sible), verification techniques (formal is safer but any other evaluation techniques can 
also be considered as a first step), and program generation. 

In that context, a modeling language such as L/P serves as an interface to elaborate, 
by successive refinements, a very precise view on the system, taking advantage of: 

- information provided by formal verification (e.g. are all assertions verified?), 

- information provided by the execution of previous prototypes (e.g. are performance 
goals met?). 

This paper focuses on program generation techniques. More information concerning 
formal verification from L/P can be found in [10]. 
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3 The L/P Formalism 

This section summarizes the main features of LfP. It is an Architecture Description 
Language with coordination facilities that focus on distributed systems. In order to en- 
hance UML models with information that enables automatic code generation of dis- 
tributed programs as well as formal verification, we define three orthogonal views: 

- The functional view describes the system software architecture, and links classes 
(that are execution units) to media (that are communication mechanisms). Both 
classes and media are described in terms of execution workflow in order to precisely 
establish behavioral contracts to be analysed and programmed. 

- The implementation view describes the system implementation constraints (target 
executive, programming language, communication infrastructure) and the deploy- 
ment topology. 

- The property view specifies properties to be verified by the system (analogous to 
the notion of proof obligation in B [1]). Such properties are stated by means of in- 
variants (for example, confirmation of a mutual exclusion), temporal logic formulas 
(for example, to the availability or fairness of a service) or other assertions that can 
be converted into a given formal method. This view can be exploited to perform 
computer-assisted formal verification. Moreover, it introduces relevant information 
for code generation (e.g. runtime checks). 



The Gas Station Example. To illustrate L/P features, let us present a model first 
introduced in [6] and then widely used to demonstrate various verification techniques, 
as in [3,24]. 

It models the simplified behavior of a self-service gas station (see class diagram in 
Fig. 2). When entering the station, a client prepays the operator, and receives a ticket 
bearing his id. The client then proceeds to the pump, inserts his ticket, pumps up to 
sum gas, and finishes his pumping operation. He then returns to the operator to get 
his change and receipt before leaving the station. Information that concern clients being 
processed is centralized in infosystem. The operator registers the client when it prepays, 
and unregisters him when he returns. The pump accesses the infosystem when a client 
activates the pump, and updates the credit when the client puts back the nozzle. 
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Fig. 2. Class diagram of the gas station. Fig. 3. L/P functional diagram of the gas station. 
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System Architecture. Fig. 3 presents the architectural diagram of the station example. 
It contains additional information that may be not present in the UML diagram, in 
order to specify communication patterns between classes. Typically, relations between 
UML classes (sometimes represented using associations) lead to the creation of media 
(here OC-chan, CP-chan, OLchan and PLchan) to describe communication semantics 
(behavior of communication elements). 

Media and classes are connected by means of binders. This notion is inspired from 
the notion of binding points in RM-ODP [8]. Binders define interaction points between 
a class instance and a media instance. They correspond to interface buffers associated 
with characteristics like maximum size, management strategy (FIFO, etc.) and overflow 
strategy (message loss, client blocked, etc.). Deployment of binders is defined by means 
of the cardinality (1 or all) specifying if they are shared or not. To avoid overloading 
Fig. 3, we only list the binders related to CP.chan and pump (cl, in-out and db-acs); 
they are referenced later in the paper. 

Let us illustrate how the cardinalities of the gas station model should be interpreted. 
Fig. 4 shows a class architecture and Fig. 5 corresponds to the corresponding object 
architecture with two instances of A and C and three of B and D. Each instance of 
class A (as well as those of class B) has its own buffer connected to the communication 
system while each instance of class C has its own buffer. Instances of D share a single 
buffer. 
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Fig. 4. Class connections: examples. Fig. 5 . Class connections: instanciation. 

There may be several interaction points (and thus binders) between a class and a 
media when different characteristics are required. This is the case between CP-chan 
and pump, in Fig. 3: in-out is a two way binder (to support remote method invocation) 
and sb-acs is a one way binder (used to propagate events). 

The behavior of classes and media introduced in the functional diagram is formally 
described using behavioral diagrams (L/P-BD). They are hierarchical state machines 
defining what action must be executed based on the internal state of a class instance. 

The architecture diagram also declares the number of classes and media instances 
to be elaborated when the system starts (this is not represented in Fig. 3). 

Behavior of a Class. The behavioral contract of a class deals with methods and trig- 
gers (an activation condition + code to be executed when the condition is satisfied). 
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Methods are invoked by other components and triggers are activated by internal condi- 
tions. Methods and triggers cannot be executed in parallel. The behavior of a class is 
expressed using L/P-BDs, a notation to express state machines. The main level defines 
the activation conditions of methods and triggers; each transition of the automaton cor- 
respond to a method or a trigger. Then, each method and trigger behavior is described 
using a L/P-BD, where transitions represent atomic actions to be performed. 

Fig. 6, defines the relationship between pump’s methods: when start is operated, 
pump_gas can be executed until finish is called. Asynchronous methods can be com- 
pared to message passing (like the asynchronous pragma in Ada-DSA [7]). This dia- 
gram also declares variables known to the class. In pump, there are only local variables 
(i.e. each instance of pump has its own copy) but class variables can also be declared 
(i.e. one copy for all instances of a given class). 



•• methods prototypes ; 
synchronous procedure start (ckJ : in i_kJent) ; 
synchronous procedure pump_gas(qt : t^volume) : 
asynchronous procedure finish : 




synchronous procedure start (ckJ : in tjdent) is 
end; -- no local variables 




c : •40fc- ' 1 :g«t_crvT.* 



Fig. 6. Behavioral diagram of class pump. Fig. 7. L,/'P-BD diagram of method start. 

Methods have to be connected to binders through which they get parameters, send 
results or invoke services provided by other classes. Triggers may also be connected 
to binders if they send/receive information from other classes. These connections are 
defined when describing the execution flow of a method (or trigger). Fig. 7 shows the 
L/P-BD that specifies the execution flow of start: 

- at tl and t2, the parameter cid of the method is extracted from the in -out connec- 
tion point when the query is issued and then copied into variable id, 

- at t3, the credit value for the client is requested through an invocation of method 
get_credit; the query message is issued and the pump instance waits until the 
value is available to assign to variable c, 

- at t3, an empty message is sent back to the client that issued the query to signal the 
execution end (start is declared as a synchronous method in Fig. 6). 

In order to get a complete view of a class behavior, the sub-diagrams that describe 
individual methods are inserted in the behavioral contract. For instance, the begin state 
of the start automata is merged with begin in the main diagram and the end state of 
the start automata is merged with s1 . 



Media Behavior. Media have no methods. The associated L/P-BD describes the com- 
munication semantics to be supported. 
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Fig. 8. Partial behavioral description of the CP-chan media. 



Let us consider the specific protocol associated with media CP.chan, that connects 
a client to a pump (Fig. 8). The L/P-BD states that: 

- only one message is handled at a time by a given instance of media CP_chan, 

- variable M stores a L/P messsage, 

- messages coming from the binder cl are routed according to the method parameter 
they transport; this is stated by means of the guards associated to transitions al 
and cl (reference to the predefined operator me thod_name). Method start goes to 
binder in-out (an answer is expected, it will be sent via transition bl) and pump goes 
to binder in (asynchronous method, no answer expected), 

- messages coming from binder in-out are all routed to cl, 

- no message originates at binder in. 



Other capabilities of L/P that are not listed here (but presented in [10, 23]) are: 

- definition of constructors to dynamically create new instances of a given class, 

- use of enhanced data structures such as arrays, records and bags, 

- definition of critical sections to protect shared variables, 

- use of predefined instructions to label transitions (basically, loops and tests), 

- assertions that are “proof obligations” for verification, and may lead to the genera- 
tion of runtime checks. 



4 Code Generation from L/P 

Code generation translates structures and operators into calls to the primitives of a run- 
time that provides procedures and services required by the L/P semantics. Generated 
programs handle distributed control of the application and thus are executed over sev- 
eral hosts. We first study the general architecture of generated applications and then 
focus on the translation procedure itself. 

4.1 Architecture of the Generated Code 

Each host that supports execution runs a partition of the system (we call it a node) 
according to the architecture presented in Fig. 9. A partition consists of classes, media 
and/or binders instances. 
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The generated application is built on top of a system-dependent layer, the runtime, 
which provides a set of standard subroutines required to support the L/P semantics. 
The interface provided by the runtime to the generated programs remains the same, 
whatever the target architecture. Therefore, for a given language, the generated code 
may be deployed on various operating systems for which a runtime is available. To 
ease the porting of the runtime, it is split in high level services containing non-platform 
specific services (garbage collection if any, buffer management, etc.), and low-level 
services containing platform specihc services (such as threading mechanisms, mem- 
ory allocation, etc.). Low-level services rely on the execution environment (operating 
system and/or communications libraries and/or middleware). 




Fig. 9. Architecture of the generated Code and its environment. 



To ensure that generated code has a minimal footprint, high-level and low-level ser- 
vices are divided into components corresponding to operations in L/P. The component 
corresponding to a given operation is embedded in the runtime if it is activated in the 
corresponding node. 

When a class or media is tagged external (e.g. it is legacy software), only interfaces 
are generated. These interfaces should be enriched if necessary to fit the implementa- 
tion of the L/P interactions strategy. For example, if one wants to use sockets, a media 
provides an abstraction of socket mechanisms that is used, first for modeling and ver- 
ification, and subsequently to generate an empty interface that can be invoked by the 
generated code. Mapping of the generated interface to sockets primitives has to be done 
manually. External components are also a way to insert hand written code into an ap- 
plication when the generated programs do not respect performances requirements. 

4.2 Generating Code for Classes 

Classes are the smallest unit of concurrency. Therefore the hierarchical automaton of a 
class, defined by means of L/P-BD, is franslated info a sequential program. It appears 
useful to maintain the hierarchical structure for two reasons: readabllity/traceability, and 
optimization of the code. The code generator must consider the following elements: 

1 . data types used by the class, 

2. local variables that are the non static attributes of the class. 
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3. LfP-BD methods that describe the execution flow of a method, 

4. shared variables that are the static attributes of the class (i.e. the variable is shared 
among all the instances), 

5. critical sections that specify synchronizations in the L/P model, 

6. evaluation of transitions guards that select the next transition to execute, 

7. evaluation of assertions to perform runtime checks on the model, 

8. connections to binders that correspond to synchronization points with a media, 

9. the LfP-BD class behavioral contract that implements the L/P-BD diagram of the 
class. 



The architecture of a class is presented in Fig. 10. The generated code for the L/P 
class is made of several interacting software units. For example, the code embedded 
in PumpPackage contains of the following elements; PumpTask which implements the 
class’s contract, PumpMonitor to synchronize the access to binders. Pump Implemen- 
tation that embeds the class’s methods and local attributes, PumpPredicates which 
contains the assertions and the guards associated to the class, PumpSharedVariables 
which contains shared variables, and PumpTypes which implements local data types. 

The class implementation is also related to global units: GlobalTypes defining 
model level types, and some Binder elements implementing the connected binders. 
For the pump class of the example, they are: in, in-out and db-acs (see Fig. 3). 




Fig. 10. Structure of the code generated for the pump class. 



Global and specific types are embedded into separate packages that easily translated 
into instructions since construction rules in L/P types are very similar to those proposed 
in conventional programming languages. Types and variables visibility is preserved to 
avoid complex renaming and ensure readability. Global types definitions are produced 
in a GlobalType component that is imported by the PumpPackage. 

Shared variables of an L/P Class are handled by a specific package (PumpShared- 
Variables). Instances of a class may be created on several nodes of the application 
and variables remain global whatever the distribution is. Therefore, the generated code 
handles consistency of these variables and provides synchronization as well as set and 
get primitives. 
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Transitions guards enable or disable transitions. If a guard only refers to local vari- 
ables, it is implemented as a boolean condition. If it refers to the body of an incoming 
message, it is implemented via a two phase transaction handled by the related binders. 
There are three primitives: Get retrieves the message from the buffer, coiranit completes 
the current transaction when the guard is satisfied, and rollback aborts it. When a state 
is followed by alternative transitions, a select-like structure is generated, as shown for 
s1 in the behavioral contract of pump (see Fig. 6). 

Assertions are also implemented as boolean expressions that may raise an exception at 
runtime. Assertions and guards are embedded into the PumpPredicates program unit. 

Methods and local variables are both implemented in Pumpimplementation. Code 
generation reproduces the automata hierarchical structure: code for transitions performs 
operations, states are associated with labels. For a given State the execution sequence 
is: 1 ) evaluation of guards, 2 ) execution of the transition body, 3 ) verihcation of asser- 
tions if any, jump to next state. 

Relation to binders are implemented using a monitor (PumpMonitor). There is a mon- 
itor for each class instance. Its role is to synchronize execution of the class with incom- 
ing messages. When a message is required to fire a transition, the program registers with 
the binder and waits until the message arrives. If a message is already in the queue, the 
invocation of the registration primitive is non-blocking. When a message is read, the 
PumpTask unit (that handles the execution contract) may evaluate a guard to decide if 
the message has to be consumed or not. 

The behavioral contract is implemented as a separate task for each instance and lo- 
cated in PumpTask. It only accepts messages corresponding to methods that are enabled 
in its current state. The current state is encoded as a local variable that selects an case 
alternative. 

To read messages from binders, the task first resets the associated monitor, then 
registers itself with binders. When a message can be read (e.g. there is a message 
respecting the transition guard), the class consumes it, unregisters from the binders, 
executes the selected method, verifies the corresponding assertions and goes to the next 
state. When no message is available or conform to the guard, the task waits on the 
monitor (sleep entry of the monitor) until a message arrives to one of the connected 
binders. 

Writing into a binder is simpler, a class instance puts the message into the binder. 

Fig. 1 1 illustrates the structure of the code generated for state s1 of class pump 
(see Fig. 6). In this state two methods are enabled; the one to be fired depends on fhe 
next binder that will receive a message. First the class resets its monitor and register 
itself with the two binders. Then it loops to check the content of both binders. If any 
valid message (e.g. satisfying the transition’s guard) is found, the class executes corre- 
sponding code, unregisters itself from the binders and jump to the next state. If no valid 
message is found (there is no message or the first one is not valid) the class waits on the 
monitor. Invalid messages are left in the binder. 
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Sl_State: 

- - reset the monitor 
Pump_Moni tor . reset ( ) ; 

- - register to connected binders 
in- out . register (this) ; 

in. register (this) ; 
loop 

-- non-blocking retrieval of an eventual message 
in - out . get (mes sage ) ; 

-- if a message exist in the in-out binder 
if message /= null then 

- - if it is a pump call and guard is true 
if Pump Predicates . Pump gas pre(messaae) then 
-- consume the message 
in - out . commi t ( ) ; 

- - execute the pump_gas Method 
Pump_Impleraentation . Purap_gas (message . qt) ; 

- - check assertions 
Pump_Predicates . Purap_gas_assert { ) ; 

- - unregister from binders 
in.UnRegister ( this) ; 
in-out.UnRegis ter (this) 

-- jump to next state (Sl_State> 
goto (Sl_State) ; 

- - unexpected messages or unverified 

- - guard, rollback transaction and 

- - try another binder 
in - out . rol Iback ( ) ; 

end i f ; 



-- non-blocking retrieval of an eventual message 
in . get (message) ; 

- - if a message exists in the in binder 
if message /= null then 

- - if it is a finish call and guard is true 
if Pump Predicates . Finish pre(messaae) then 

- - consume the message 
in . commit ( > ; 

- - unregister from binders 
in.UnRegister (this) ; 
in-out .UnRegister ( this) ; 

- - execute the finish method 
Pump_Implementation . Finish ( ) ; 

- - check assertions 
Pump_Predicates . Finish_assert ( ) ; 

- - jump to next state (Begin_State) 
goto (Begin_State) ; 

else 

in. rollback ( ) ; 

- - Sleep on the monitor until next message on 

- - registered binders 
Pump_Monitor . Sleep (wait_delay) ; 

end loop 



Fig. 11. Pseudo-code of pump related to state s1 and activation of methods pump_gas and finish. 



4.3 Generating Code for Media 

Media are communication mechanisms between classes. Two strategies are considered. 

When it is tagged “external”, the media corresponds to legacy software (a com- 
munication library). Only an interface defining the functions required to interact with 
associated binders has to be generated. The media definition is used first for modeling 
and verification purposes, then to generate an empty interface to be invoked by classes. 
For example if a designer wants to use sockets, the corresponding media provides ap- 
propriate interfaces and abstraction. Mapping to the socket library has to be done man- 
ually; the resulting component is reusable. Off-the-shelf media will be provided (such 
as sockets or RPC). 

When it is tagged “internal”, a media is translated into an automaton implementing 
the specified protocol. 

Media also allow support the definition of implementation-independent higer level 
communication mechanisms. For example, a channel media may encapsulate various 
types of implementations: sockets, shared data segments, etc. Such abstractions are of 
interest to ensure portability over several target architectures (hardware + operating 
system). 

4.4 Generating Code for Binders 

Binders are connection objects between instances of Classes and Media. They are im- 
plemented as distinct code units. There are several implementation schema depending 
on their characteristics: multiplicity, blocking/non-blocking primitive access, etc. Im- 
plementation strongly relies on the L/P runtime that provides generic message passing 
and instantiation services. 
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generic class Blocking_f if o (Size, Message_type, Client_ref_type) 
begin 

protected entry Put (Message : in Message_type) when not transaction; 
protected entry Get (Message : out Message_type) when not transaction; 
protected entry Commit (} when transaction; 
protected entry Rollback (} when transaction; 

protected entry Register (Client : in Client_ref_type) ; 
protected entry UnRegister (Client : in Client_ref_type) ; 

private : 

Buffer is array (l..Size) of Message_type; 

First, Last := 1; 

No_i terns := 0; 

Client_list is list of Client_ref_type; 

Transaction is Boolean := FALSE; 

end; 



Fig. 12. Specification of a blocking FIFO. 



Binders are implemented as instances of generic templates to enable pattern reuse. 
Fig. 12 shows the pseudo-code of binders interface (here, a FIFO buffer). This template 
has three generic parameters: size (capacity of the buffer), message_type (type of 
transported data), client_ref_type (reference type to designate clients). 

Private data implement a fixed size FIFO, a list of subscribers and a boolean variable 
to indicate if a get transaction is currently running. 

Access to the template services are protected (i.e. both mutually and self exclusive). 
Put, get, commit and rollback are I/O primitives while Register and Unregister 
are dedicated to client management. Get starts a transaction. Commit or rollback en- 
tries end the transaction. Pending Put or Get are executed only when no transaction is 
running. 

4.5 The L/P Runtime 

The runtime provides a set of services to handle the L/P semantics using primitives of 
the target execution environment. The runtime provides the following services: 

- Task management service deals with creation, synchronization and termination of 
the tasks that handle the execution contract of classes and media (e.g. PumpTask in 
Fig. 10). It is also a basis for implementing class monitors (e.g. PumpMonitor in 

Fig. 10). 

- Resource management service handles creation, initialization and destruction of 
LfP code elements (classes, media and binders instances). 

- Registry service (in the meaning of Java-RMI [16]) stores global references to gen- 
erated code units and runtime units at execution time. It is required for distributed 
deployment when naming conventions have to be preserved over several adresses 
spaces. This is the case when a prototype is deployed on two middlewares (e.g 
CORBA and Ada/DSA). 

Fig. 13 presents in the form of an UML class diagram the relationship between the 
L/P runtime and the application. This interaction model is inspired by RM-ODP [8]. 
The runtime contains three logical units dedicated to management: 
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LfP runtime ' LfP application 



Fig. 13. Relationship between the L/P runtime and applications. 



- The application manager handles initialization, termination and error management 
for the application. It relies on node managers to supervise hosts specific tasks. The 
Registry service is implemented in the application manager since it is used by all 
the components of the application. 

- Each node manager handles a partition of the application on a given node. It im- 
plements process creation which is part of the runtime task management service. 

- Each capsule manager handles instances of a given class or media within a given 
partition. It supports both task and resources management services. 

The runtime implementation depends upon the selected execution environments. 
There are two types of execution conditions: 

- Some applications focus on the use of thick execution environment such as CORBA, 
Ada-DSA or JAVA-RMI. These environments offer sophisticated services such as 
naming, dynamic remote creation of objects, etc. 

- Other applications have critical time and/or memory constraints. They require thin 
execution environment such as QNX [21]. Code generation also requires specific 
strategies to minimize memory footprint or optimize execution time. 

The runtime architecture presented in Fig. 13 is able to fit those two types of con- 
straints with tolerable performances. The use of a thick execution environment is not 
a problem since they support most of the functions required in L/P. The runtime is 
then minimal but relies on more complex services. The use of thin execution environ- 
ments requires a more complex runtime that relies on very simple but efficient services. 
However, it is possible to write most of the L/P capabilities with respect to the require- 
ments of embedded systems. For instance a partition may include a static scheduler that 
handles instances of L/P classes as threads taken from a pool whose size is fixed at 
compilation time and yet be compatible with an interpretation of Fig. 13; then, many 
components are reduced to very limited code. 
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5 Conclusion 

This paper presents a model based development approach for distributed applications. 
It relies on L/P, a notation to capture the behavioral semantics of such systems, and 
serves as a basis for both formal verification and automatic code generation. 

We consider that such an approach is a valuable extention to UML based design 
methods. The combined approaches (UML for object-oriented design and L/P for a 
process-based implementation) offer a way to move from an object oriented design to 
a communicating processes oriented implementation (which is more natural for dis- 
tributed systems) and provides independence from middleware. Our approach also en- 
ables the use of formal methods as described in [10]. 

We propose a mapping of L/P concepts to a generic architecture that can be im- 
plemented on top of various execution environments. This is a way to help engineers 
to design and implement complex systems without getting into the often complex and 
delicate task of using sophisticated middleware services. 

Our generic architecture relies on a runtime that virtualizes the execution environ- 
ment. This is of particular interest when the application executes on several hosts run- 
ning different operating systems. Effort expended on the implementation of the runtime 
on a given target architecture can be reused for future applications. 

Future work aims to provide a set of coherent tools based on L/P. This is the goal 
of a project founded by RNTL (Reseau National des Technologies Logicielles, a french 
label and founding provided by the government for cooperation between industry and 
universities), dedicated to embedded distributed systems, that started in July 2003. 
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Abstract. Software components have been a long-standing dream of the 
software engineering community since the birth of software engineering 
itself in 1968. Every few years, it appears that we are on the verge of 
discovering exactly what a software component is. On the other hand, 
due to changes in technology and application environments and domains, 
our view of, and requirements for, components also changes. We review 
the changing nature of software components and discuss some of the 
challenges to the idea of components to be faced due to the advent of 
pervasive computing environments. 

Keywords: pervasive computing, components, generic component 
model, component interoperability, dynamic adaptation 

1 Introduction 

The essential idea of software engineering is to systematically construct software 
out of parts that we now call components [17]. There are many definitions for 
components and the definitions evolve over time, sometimes due to new capabil- 
ities in programming languages, sometimes due to new programming or design 
paradigms, and sometimes due to an application domain requirement. Over time, 
components have referred to routines, abstract data types, objects, executable 
modules, etc. 

Today, our agreements about the nature of software components are codified 
in the many available component models, including OMG’s GORBA Gompo- 
nent Model (GGM), Microsoft’s GOM-b and .NET, and Sun’s JavaBeans and 
Enterprise JavaBeans. 

Yet, as we are beginning to agree on what software components are, the 
emerging pervasive computing environment is set to once again challenge our 
notion of software components by introducing a completely new set of require- 
ments for software components. In this paper, we review the evolution of software 
components and the general trends in the area. We present the Vienna Gom- 
position Technologies (VGT) as representatives of the state-of-the-art compo- 
nent and composition techniques. We then discuss the new pervasive computing 
paradigm and the resulting requirements imposed on software components. We 
present some ideas on how VGT may be changed to meet these new requirements. 

The paper is structured as follows. Section 2 presents state-of-the-art com- 
ponent and composition techniques. In Section 3, we formulate the requirements 
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of component based software engineering in pervasive computing environments 
and in Section 4 we show two typical applications that benefit from a pervasive 
computing environment. On the basis of these requirements and application sce- 
narios we discuss in Section 5 how VCT will have to be extended for pervasive 
computing environments. In Section 6, we present Work related to our approach 
and in Section 7, we draw our conclusions. 

2 State of the Art in Software Components 

Before discussing the role of software components in a pervasive computing envi- 
ronment we review the current state of the art of component technology. On the 
basis of this discussion, we can then define the requirements for the pervasive 
computing environment. 

A software component is a unit of software that adheres to a well-defined 
contract defined by the interfaces it implements [18,22]. These interfaces define 
the features a component provides. Such features may be methods, properties, 
events, or other communication and configuration mechanisms. A software com- 
ponent does not live on its own but is part of a component model that defines 
the basic architecture and characteristics of the components [4] . Run-time query 
capabilities reduce the limitations of earlier strongly typed models to allow dy- 
namically defined interactions among modules. 

The component-based software engineering paradigm is based on assembling 
(or composing) applications from independently developed components. On the 
other hand, independently-developed components may have incompatible in- 
terfaces in the sense that components that could interact with each other on 
a conceptual level may not be able to because of a mismatch in their inter- 
faces. To solve this problem, different adaptation techniques have been devel- 
oped. Example adaptation techniques are wrapping [11] and type-based adap- 
tation (TB A) [8] . Wrapping is a manual adaptation technique that requires the 
developer to define the adaptation manually wheres TBA selects previously- 
written adapters from an adapter repository and automatically determines how 
the adapters need to be combined in order to translate between the components’ 
interfaces. 

We can say that the major characteristic of the current software compo- 
nent technology is components with well-defined interfaces. This characteristic 
supports composition of components based on an application’s architectural de- 
scription, and also automatic matching and possible adaptation of components. 

As a concrete example, in the next subsection, we will discuss how the issues 
of component models, component adaptation, and architecture description are 
addressed by the VCTs. After that, we will review the requirements of pervasive 
computing and discuss how our solutions must be changed and adapted to meet 
the new requirements. 

2.1 The Vienna Component Framework 

One technology of the VCT is the Vienna Component Framework (VCF) [20], 
supports interoperability and composability of components from different com- 
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ponent models. It provides a single Java API that allows developers to reuse 
components implemented for different component models from within one single 
application. Since VCF abstracts from the internals of the component models, 
the developer no longer needs to deal with the difficulties and differences inherent 
to these models. 

VCF uses a plugin architecture which allows developers to add support for a 
new component model through the implementation of a single plugin. Currently, 
we have implemented plugins for JavaBeans and Enterprise JavaBeans, Microsoft 
COM+, CORBA distributed objects and are working on plugins for SOAP, used 
for web service communication, the CORBA component model (CCM), and the 
Microsoft.NET framework. 

Each plugin has to provide the access mechanisms to the features of its un- 
derlying component model. This includes features to control the life cycle of 
a component instance, features for accessing a component instance’s state and 
using its operations and those to make a component instance persistent. How a 
feature is modeled and accessed internally is up to the plugin, but externally the 
plugin provides a standardized interface. For instance, a method feature exists 
in all component models and handling the abstraction was relatively by intro- 
ducing a method interface. Events, on the other hand, have different concepts 
in different component models. Nevertheless, VCF allows the use of events with 
plugin implementations. 

A single fagade class is used to access the features exposed by the plugins. 
With VCF, components, such as COM-I- or .NET components, that have no 
direct support for the Java programming become accessible. 

2.2 Type-Based Adaptation 

One of the key problems of building applications out of components is what to 
do if the component you need is unavailable in the catalogs you have. Clearly, 
no catalog will have every component that an application developer needs. But, 
often, there will be a related component, or one that is almost the one needed. 
One option for the developer is to modify the related component to make it fit 
his needs. This approach defeats the purpose of component-based development 
because for the fundamental reason that it breaks the separation of concerns be- 
tween component development and component usage. A better approach would 
be to automatically adapt the components. 

VCF abstracts the access to the features of components of different compo- 
nent models but does not try to adapt their interfaces. Such kind of adaptation, 
however, is necessary if one component provides the functionality expected by 
another component but provides an interface slightly different from the one ex- 
pected. This kind of adaptation, however, is accomplished by TBA [7,8]. 

TBA relies on a repository that stores previously built adapters and a meta- 
description of the transformations the adapters perform. The minimal require- 
ments for this meta-description is the list of interfaces that an adapter is able to 
understand and those it is able to provide. TBA requires the ability to identify 
the required and provided interface during run-time. The required interface can 
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be identified on the basis of how the component is instantiated and the provided 
one using an interface repository which is provided by VCF and by modern 
component models. Once a collection of adapters is available, TEA adaptation 
exploits these features to automate the adaptation process by deciding when a 
adapters are needed and how they are to be applied. 

More importantly, TEA can determine when it is necessary to chain several 
existing adapters together to effect an adaptation that is more powerful than 
any one existing adapter can do by itself. This ability to chain adapters together 
greatly increases the power of the process and requires many fewer adapters to 
be written by the programmer directly. We only have to define rules on when 
two adapters may be combined. In the simplest case, one adapter provides the 
interface that can be used by another adapter and hence, they may be combined. 
A detailed discussion on how more complex adapters can be built out of simpler 
ones can be found in [7] . 

The advantage of component adaptation is that a developer can provide a 
minimal catalog of components while the user still gains the benefits of a larger 
catalog. This was also the goal of the work reported in [15] but in a context that 
did not require the automated adaptation of software components. 



2.3 Application Composition Language 

To generically describe applications built from components, we have developed 
an Application Composition Language (ACL/1) [19]. This language allows for the 
explicit description of the application’s architecture and its architectural proper- 
ties. Similar to ADLs, our language provides constructs to describe components 
and their connections. The advantage of ACL/1 over typical ADLs, however, is 
that it can be executed by means of interpretation or compilation. 

ACL/ 1 uses VCF for the representation of components and hence supports the 
composition of components that have been developed for different component 
models. ACL uses four different concepts: component descriptions, connector 
descriptions, configurations and frameworks. Components are the elements of 
computation in our language while connectors comprise the glue between com- 
ponents. Configurations describe how particular components and connectors are 
instantiated and arranged to make a concrete application. Frameworks are con- 
figurations in which several components and connectors remain unbound to con- 
crete components or connector types. Frameworks are comparable to generics in 
object-oriented programming languages. 

Unlike most ADLs, our composition language is not restricted to a predefined 
set of components or connector types but can be extended arbitrarily. ACL/1 
allows developers to provide new types of connectors or to define frameworks 
that act as generics for components or connectors. Our current language format 
is based on XML since XML parser frameworks are widely available and ready to 
use. Although XML can be easily analyzed with software tools human beings find 
XML difficult to read. Hence, we have built a graphical composition environment 
that can store, read and execute ACL descriptions [19]. 
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3 Requirements of Pervasive Computing 

The pervasive computing environment of the future will be characterized by 
many invisible sensors and computing elements, autonomously interacting with 
each other to dynamically construct and provide services to users that enter 
and leave the environment. Pervasive computing lies at the intersection of dis- 
tributed systems, embedded systems, and telecommunications. Pervasive com- 
puting poses many challenges to software engineering and other disciplines. We 
certainly will have to revisit the ideas of components and component models, 
and how we should model, analyze, build, and deploy such components in a 
pervasive computing environment. 

3.1 What Is a Component 

The pervasive computing environment will force us to face the need for com- 
ponents and their boundaries more clearly. Indeed, complex applications will 
have to be composed from individual components residing in a large number of 
heterogeneous computing elements. The hardware environment itself will force 
a natural boundary between components. A component is an independently de- 
ployable piece of software that resides on one hardware element and provides 
a service element. Of course, there may be more than one component on each 
hardware element. Just as Web Services are emerging in the Web computing 
infrastructure as a component, some form of components will have to emerge 
in the pervasive computing infrastructure. Perhaps a component will also be a 
Web service, accessible through a URL? More likely, however, it will be a peer 
service with a well-defined protocol. 

Component interaction mechanisms will also have to evolve. Traditional invo- 
cation based interaction mechanisms are probably inadequate to meet the needs 
of a large number of expected components and the wide heterogeneity of their 
interactions. Invocation mechanisms will have to allow for a much more loose 
coupling of components. Mechanisms such as event-based [1] interaction provide 
a higher degree of component independence and application scalability. 

3.2 Need for a Scalable Component Model 

Current component models are rather homogeneous in the kind of components 
they support. Components are basically of the same size and power. For exam- 
ple, JavaBeans components [10] are for desktop environments while Enterprise 
JavaBeans [4] are for server and enterprise-wide components. To make applica- 
tion development manageable, we need a component model that is scalable in 
the sense that it supports the development of components of various granulari- 
ties, components that can reside in tiny computing elements, such as wearable 
computers, but can also grow to take advantage of resource-rich computing el- 
ements such as laptop machines and even larger fixed server machines. This is 
currently a real problem, even for a single programming language. Java has sev- 
eral versions of its JVM [24] for resource-poor and resource-rich environments. 
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You need to think differently about the component model if you are designing 
for a smart phone or for a laptop. In a scalable component model, at least the 
modeling and analysis techniques must span a range of granularities. 



3.3 Need for Dynamic Adaptation and Composition 

The pervasive computing use-case scenario envisions that the environment ad- 
justs to new participants in the environment. It should not only provide services 
to the new participants but also use the resources offered by them to construct 
new services. For example, someone with a digital camera enters a room, au- 
tomatically enabling a photo printing service, by combining the digital camera 
and the already-existing printing service. If another component exists that can 
convert photo resolutions, it is then possible to offer photo printing at vari- 
ous resolutions. If an image database exists, and photo album services are also 
available, new services can be dynamically configured. 

This scenario implies that the computing infrastructure must be able to dy- 
namically identify new software components to cooperate with and that they 
must be adapted to a constantly changing component catalog. This kind of ad 
hoc composition requires a higher degree of interface adaptation and mapping 
than is common today. Perhaps some components can provide interface adapta- 
tion services to enable a wide variety of component interoperation. Such adap- 
tation services should probably be a standard but evolving part of the common 
infrastructure. 

In a pervasive computing environment in which the catalog of available com- 
ponents changes constantly the adaptation that has to be performed is only 
known at run-time. Hence, an effective approach that automatically adapts the 
existing component to the need of the application is necessary. The VCTs deal 
with the concern of automatic adaptation with TEA. In pervasive computing, 
however, adaptation may also be necessary to adapt components to different 
devices, enabling components to move from device to device which is not yet 
addressed by TEA. 



3.4 Need for Security and Access Control 

An apparent serious conflict in the pervasive computing environment is the inter- 
play between openness and security. A basic premise of the environment is that 
components dynamically recognize each other and cooperate with each other. 
On the other hand, such an open environment requires strict control over re- 
sources. You may not want to offer all available services to every new element 
that enters the environment. We need a lightweight mechanism because it has 
to be used heavily. A reasonable idea is that the application components carry 
“tokens” or capabilities that authorize them to access or provide services. Once 
an application component has obtained a token, the component uses this token 
for its authentication. The low-level communication mechanism is responsible 
only for secure communication among authorized parties. 
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The need to combine security and access control with dynamically interacting 
components of varying granularity may be the biggest challenge of component 
composition in the pervasive computing environment. 

4 Two Scenarios of Pervasive Computing 

The term pervasive computing is applied broadly and many visionary scenar- 
ios are offered as applications of pervasive computing. Applications have been 
described for the smart home [14], smart office [25], smart classroom [2], smart 
healthcare [23], and other such environments. The research also covers sensors 
and other hardware devices, networking, and software architectures. Here we 
describe two simple scenarios that exhibit the characteristics of pervasive appli- 
cations. We concentrate on software components and do not refer to any partic- 
ular embedded hardware devices. The purpose of these scenarios is to show that 
simple pervasive computing capabilities can indeed provide useful services, and 
that we can try to build the software infrastructure for supporting these services 
and experimenting with them without waiting for future embedded hardware to 
become available. 

4.1 Meeting Manager 

In today’s globalized environment, it is common to have project or other kinds 
of meetings where the participants are from different countries and different 
organizations. The group meets in a hotel or company conference room. In a 
typical meeting, all participants own their own laptop or digital organizer. The 
participants may take turns to make presentations to the rest of the group. There 
are discussions about particular issues, decisions are taken, and action items are 
agreed upon. 

Let us take a very simple example: agreeing on the next meeting for the 
project. The typical situation is that all pull out their electronic calendars and 
start checking for available dates. A very successful technique consists of one per- 
son writing their proposed dates on a blackboard and others crossing out some of 
those dates based on their current commitments as shown on their calendar. The 
hope is that some date will be free from all conflicts. This situation should lend 
itself to the pervasive computing paradigm: after all, all the relevant information 
is already stored digitally and all that is required is the seamless integration of 
the data and their coordination. In this sense, the pervasive computing hardware 
infrastructure already exists. 

From the software point of view, if we imagine a meeting-manager applica- 
tion, the application faces the important pervasive computing requirements: 

Heterogeneous components: The application consists of components that 
reside on heterogeneous devices (computer or organizer), each supporting a 
different calendar program; there is no possibility to limit the list of calendar 
components to only a single manufacturer. 




Pervasive Challenges for Software Components 159 



Spontaneous and ad hoc networking: The components that form the ap- 
plication are not predetermined; they come together just because the own- 
ers happen to be part of this particular meeting; the components must be 
prepared to communicate and cooperate with a dynamically determined set 
of components. 

Security administration: The calendar components should somehow be able 
to provide public information to legitimate components and protect private 
information from everyone. 

We can imagine a simple controller application that is able to communicate 
with diverse calendar components, request information from them about par- 
ticular dates and appointments, applying some algorithm to determine the best 
dates, and upon approval of the date, sending the accepted date to all calendars 
to update their individual entries. Where this application resides is an interest- 
ing question. It can reside on a server at the meeting conference room or it could 
be hosted by any of the devices that also has a calendar. Indeed, it can even 
float from one machine to another, as a piece of mobile code, depending on its 
design. The main point is that the application takes advantage of the pervasive- 
ness of computing elements and the existence of all the information in digital 
and communicable form. 

4.2 Museum Tour Guide 

The meeting-manager scenario presents our view of pervasive computing appli- 
cations: an application is a skeleton or description of a service whose implementa- 
tion relies on components that become available, or are discovered, dynamically 
depending on the environment. In that scenario, the components were rather 
homogeneous in that they were all calendars. In this scenario, we consider many 
different kinds of components. Consider a museum-tour-guide application. A 
museum patron, equipped with a computing device enters a museum. The Tour 
Guide application designs and proposes a particular path for the patron to follow 
through the museum, on the basis of the patron’s preferences and choices. As 
the patron walks by each painting, descriptions and information of particular 
interest to the patron is displayed on his organizer or spoken through his phone. 

Again, the question of where the application resides is interesting. There 
could be tour and album organizer on the museum’s server, which negotiates 
parameters of interest with the patron’s computer. Or the application could be 
on the patron’s computer, already customized for his preferences. Perhaps an 
album is already partially filled with data from other museums and only a few 
more items will be added from this museum. The common theme between this 
scenario and the previous one is that many components are involved: notepad, 
tour planner, and so on, and that these components may be offered by different 
computers that are dynamically determined. 
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5 Component Composition 

in Pervasive Computing Environments 

As we have seen in the scenarios, the pervasive computing environment moves far 
away from the current component models (and long-term trends) that assume 
a mostly static environment. The pervasive computing environment is in fact 
characterized by volatility. Before we present how VCT need to be adapted, we 
discuss how we map components and component descriptions to the pervasive 
computing environment. 

We assume a large number of devices, which we call pervasive computing 
devices. A component resides on a single pervasive computing device. Each com- 
ponent can provide functionality that is primarily of interest to the local device 
such as an image viewer component. Additionally, it may provide functionality 
that might also be of interest to other components probably residing on a dif- 
ferent device. Such a service, for instance, could be a dictionary or a printing 
service. Since VCF is able to cope with desktop component models and server 
component models, it provides already a good fit for pervasive computing envi- 
ronments. 

To build more powerful applications out of the available components com- 
ponents need to be composed. This can be done using ACL/1, our application 
composition language. In our current model, a single application description is 
available on a single device and is not distributed over multiple devices. An ap- 
plication description again can be seen as a component, with the exception that 
its functionality may be provided by components located on several different 
devices. 

Application descriptions will have to communicate with many different com- 
ponents that provide the same kind of service but through different interfaces. 
Since these interfaces and the adaptations necessary, we need a powerful adap- 
tation mechanism such as TBA. TBA has already been used for dynamic dis- 
tributed systems which provide a similar environment but on a larger scale. 

For this setup to work correctly, however, the following questions need to be 
answered: 

— On which device should the application description be located? 

— How can components be located on other devices? 

— How should components be adapted? What types of adaptation exist? 

~ How do we deal with devices and components that enter or leave the envi- 
ronment? 

To answer these questions, we imagine a pervasive computing environment as 
shown in Figure 1. The following sections discuss how this environment addresses 
the above problems. 

5.1 Application Descriptions 

The application server is intended to contain standard application descriptions 
in the particular physical location where this environment exists. For example. 
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Fig. 1. Component-Based Pervasive Computing Environment. 



it might run a meeting manager application or a museum tour guide applica- 
tion. The application descriptions and the components that form the application 
reside in different places and may move in and out of the environment. 

We can identify two possible alternatives for where an application description 
can reside: either it is resident at a home location and uses the services or com- 
ponents that enter its neighborhood, or it may reside on one of the devices that 
enters the neighborhood. Both possibilities are viable and offer distinct advan- 
tages and design choices. In the meeting scenario, for example, the application 
description might be present on a notebook computer of one of the participants. 
In the guided tour scenario, on the other hand, the application description could 
be located at the museum’s server and could be downloaded by its visitors into 
their PDAs. 

We can see the difference between the pervasive computing environment and 
the current component technology by trying to imagine what application de- 
scriptions might look like. In conventional environments, the components that 
form the application and their interconnections are listed. In a pervasive com- 
puting environment the list of the components is not necessarily known and 
certainly the interconnections are not known. Therefore, the components must 
be identified mostly by their properties. 

Our application composition language allows us to use both approaches. 
Firstly, it stores the names of the components that have been used for the ap- 
plication and secondly, it stores the features of the components that have been 
used. This allows the system to look up the component by its name and if that 
component is not available to use the features of the component as the list of 
requirements for a possible substitute component [9] . 

5.2 Locating Components 

In a static computing environment, a central service could be used for the lo- 
cation of the available components. Due to the variety of different devices and 
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their mobility, however, this solution cannot be chosen. A possible solution is to 
use a distributed membership service where the devices register themselves as 
well as the components they offer. Since not every device is capable of providing 
such a service we propose the use of supernodes that maintain such a registry, 
an approach similar to that used in peer-to-peer networks [16]. 

A simple device may broadcast a request to locate the supernodes located 
within its vicinity. As soon as a supernode replies, it adds the node to its list of 
reachable supernodes and registers its own services with the supernode. When- 
ever the device needs to locate a component it queries the supernode. 

5.3 Adaptation 

Another element in our environment is component adaptation. Since we expect 
much more heterogeneity in the pervasive computing environment, we expect 
the need for many more component adaptation technologies than exist today. In 
a pervasive computing environment, the devices that need to interact with each 
other are constantly changing. Hence, components need to be able to interact 
with a wide range of components found on other computing devices. The frame- 
work we have presented in Section 2.1 is able to provide an environment to allow 
components implemented for different component models to interact with each 
other. 

One drawback of VCF is that it still requires the interfaces provided by 
one component to match those requested by another component. In a pervasive 
computing environment such a component might not always be available but 
there might be a component providing the same functionality with a different 
interface. The adaptation has to be performed at run-time since the devices that 
need to communicate with each other and the communication protocols they 
use are not known a-priori. Since users of such devices do not want to deal with 
incompatibilities, the adaptation has also to be performed automatically. 

One such adaptation technique, operating on the component’s interface level, 
is TEA [7]. As explained in Section 2.2, this kind of adaptation is achieved 
with the use of an adapter repository. Indeed, we categorize adapters into many 
different classes, some of which are shown in figure 1. Adapters may be needed 
for adapting the interface of a component, or transform the data it provides to 
its clients, or the protocol it follows for providing the data. 

We believe the organization of this repository, and the issues surrounding its 
population are particularly interesting. The organization of the adapter repos- 
itory is key to the success of TEA. Without such a repository, adaptation is 
not possible. Since pervasive computing devices have a small memory capacity 
compared to desktop computers and since we cannot assume that these devices 
will have Internet connectivity, a central adapter repository cannot be used. 

An interesting way to exploit component adaptation to deal with the volatil- 
ity and unpredictability of pervasive computing is to maintain an adapter repos- 
itory at each site. The idea is that each site would maintain a set of adapters 
that can be used to adapt the components available on its own device and hence 
increasing the number of components it is able to interact with. When a new 
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device enters the site, the adapters in the repository can be used to help it match 
the interface requirements of available services. 

Such a setting makes it also possible for the new device to share its adapters 
with other devices available. This allows a device to download an adapter that 
could be useful for the device and carry it away. Other types of adapters may be 
used to control the behavior of incoming components to respect the requirements 
of the host environment, for example in terms of security. Yet other adapters may 
be used to provide more limited versions of existing services to untrusted arriving 
components. 

5.4 Environment Volatility 

Components and application descriptions float in and out of the environment, 
and sometimes compose to provide a service. Hence, pervasive computing en- 
vironments carry the concept of partial failure to an extreme. At any moment, 
components of an application may disappear, as indeed may the whole applica- 
tion, leaving its components as orphans. Thus, a strategy is needed to deal with 
not only newly arriving components but also departing components. 

Depending on the kind of the departing component, we have to deal with 
the failure differently. If the departing component does not maintain any state 
on behalf of the application, the infrastructure can deal with this kind of fail- 
ure and look for a different component providing the same type of service. If 
the component, however, maintains part of the application’s state, we have two 
choices: transferring the state before the component departs and maintaining 
checkpoints. 

The transfer of the component’s state is only possible if we can anticipate 
when it is likely for a component to become unavailable. If the devices use wireless 
communication, this could be identified using the signal strength of the device. 
In this case, we would have to transfer the state maintained by the device to 
another device. The representation of the state, however, needs to be converted 
to that used by the target device which again involves one of the adaptation 
approaches mentioned above. 

If we cannot identify when a device leaves, or if the state of the departing 
device leaving cannot be used by any other devices left, the only chance is to 
revert to a previously stored checkpoint. Unfortunately, maintaining such check- 
points cannot be done in a general way, hence this issue has to be dealt with by 
the application itself. 

5.5 Resource-Poor Devices 

The heterogeneity of devices poses a challenge to the uniform integration of 
components and devices in an environment. On the one hand, we would like 
to treat all devices uniformly so that they can respond to queries and engage 
in interactions following similar protocols. On the other hand, many pervasive 
devices do not have sufficient power to process, or memory to perform such tasks. 
We, therefore, assume a proxy server at each physical site that represents small 
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embedded devices in the environment. These devices register or are registered at 
the proxy server along with their relevant properties to allow the proxy server 
to manage the environmental interaction with these small devices. 

6 Related Work 

Project Aura at Carnegie Mellon University (http://www-2.cs.cmu.edu/~aura/) is 
a very large project addressing the whole range of pervasive computing topics 
including speech recognition, wireless networking, and other areas. It is billed as 
distraction-free ubiquitous computing and its aim is to do as much as is possible 
automatically so that the user can concentrate on end-user tasks [6]. 

The software architecture envisioned by project Aura consists of three layers: 
a runtime layer that manages the environment, a model layer that maintains a 
model of the system architecture and ensures that needed resources are available, 
and a task manager that is responsible for performing user tasks. A user task, 
which is similar to what we have called application in this paper, is a collection 
of abstract services provided by the environment. The task manager monitors 
and optimizes resources for the use of the tasks while the model layer optimizes 
across the whole architecture in the environment. 

Project Aura is focused on system aspects, while we are most concerned with 
component composition issues. They assume component interaction mechanisms 
to be built on top of available mechanisms such as provided by CORBA. The 
project deals with architectural adaptation in the sense of adapting to changes 
in the environment such as effected by user motion or departure of needed com- 
ponents [3]. This kind of adaptation is different from what we have described 
as type based adaptation. However, such adaptations are also important and 
it is interesting to see if it is possible to apply them as component adaptation 
techniques rather than architectural adaptations. 

The Rome architecture [13] is based on context triggers. Triggers invoke the 
right services when the context requires it. For example, a driver is notified when 
he is driving near a supermarket that he needs to stop and pick up some new 
drinks for his party the next day. The context of the party and lack of drinks 
in the refrigerator are maintained in the infrastructure and appropriate actions 
are triggered when necessary. 

A number of authors have discussed infrastructure services and designs for 
pervasive computing such as for a museum [5]. The Gaia operating systems [21] 
extends the services of a traditional operating system to a pervasive environ- 
ment. An overview of software engineering research challenges in pervasive com- 
puting [12] includes a discussion of components and their requirements. 

7 Conclusions 

The ever-advancing hardware possibilities have necessitated fundamental changes 
in the way we design and build software systems. The major shifts in the past 
have been from centralized software to client-server to distributed. One major 
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shift appears to be towards pervasive software which is supported by a hardware 
environment that consists of large numbers of computing and communication 
elements. The environment is characterized by heterogeneity and volatility, in- 
troducing challenges and open problems in every software lifecycle phase: mod- 
eling, analysis, specification, validation, deployment, and additionally, security. 
Traditionally, software engineering solutions have tended to favor static descrip- 
tions and validation approaches. This tendency will have to be abandoned in 
order to deal with the highly dynamic nature of pervasive environments. 

Independently of how we approach the software lifecycle phases, and how 
we structure the infrastructure, middleware, and applications in this new envi- 
ronment, one of the fundamental issues we have to face is the role of software 
components. We need to be able to compose services out of a highly ad hoc 
and dynamic set of potentially untrusted components. In this paper, we have 
presented the requirements for software components in a pervasive computing 
environment and defined a software component as a unit of deployment. We 
have reviewed the VCT as representatives of today’s component composition 
environments. We have discussed how the basic component operations of defini- 
tion, composition, and adaptation have to be modified in order to cope with the 
requirements of pervasive computing. 
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Abstract. We propose the use of (semi-) automatically extrapolated 
models as a means for coping with legacy systems: a focused way of 
testing systems for their behavioral properties allows the construction 
of expressive behavioral hypothesis models, and therefore extends the 
range of formal methods to ‘black box’ scenarios, which are dominant 
in industrial practice. Keeping these models up to date by continuous 
adaptation may provide an ideal way for controlling the evolution of 
large systems during their whole life cycles. Bottleneck of this approach 
is the size of the extrapolated models: particularly for distributed sys- 
tems the state explosion problem strikes back. This paper focusses on 
a particularly promising cure: view- oriented model construction allows 
a new way of size control that complements other powerful techniques, 
which together have the potential to scale to systems of realistic size. 
This is illustrated by considering small instance views in the context of 
Computer Telephony Integrated Systems. 



1 Motivation and Background 

Models are the key for the design of complex systems, accompany their devel- 
opment, and serve as powerful means during the maintenance. In fact, without 
them, the interaction with a potential customer remains vague, and there is no 
sound basis for a contract. This commonly agreed upon statement has however 
little practical impact, because - despite the recent developments like the Unified 
Modelling Language (UML) - building models, and even worse, keeping them up 
to date, is time consuming and expensive, thus not adequately taken care of. 
The lack of adequate, up-to-date models indeed causes misunderstandings, leads 
to unexpected side-effects in new releases and is the reason for many unsatis- 
fied customers. The following three subsections summarize this situation with 
special attention to legacy systems, which, in fact, are dramatically dominant in 
the industrial practice, and propose a pragmatic way out: automating the bulk 
of the model construction and maintenance effort by exploiting techniques from 
automata learning. In fact, (semi-) automatically generated models (almost) ‘for 
free’ seem to provide a good compromise in the precision/cost trade-off. Once 
this technology is accepted, deeper modelling techniques, like those e.g. aimed 
at with UML, may be easier to introduce into current design practice. 
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1.1 Status Quo and Needs 

Component-based software engineering as supported by CASE tools, portable 
programming systems (like those centered around Java), and universal modelling 
tools like those based on UML have changed the pragmatics of modelling and 
programming environments. The new tool support has successfully enabled a 
wealth of applications that now ease - or at least accompany - our daily life. 
However, there is still a long way to go before the promises of modern software 
engineering become everyday reality. This concerns at least the “popular” ex- 
pectations, easily excited by slogans like “write once, run everywhere” (which is 
true only once you have the adequate virtual machine, which might be cumber- 
some in practice) , or by the hope-belief that complexity is tamed by reusability, 
and that reusability comes for free as soon as one follows a few lightweight rules 
of thumb. Even worse: there are still major problems to solve, which seem to be 
out of reach of the state-of-the-art paradigms. Examples are: 

— Customer integration: how can we build models that are comprehensible 
to the customers, but at the same time sufficiently precise so that they can 
constitute a good basis for design and implementation? Or, even better, how 
can we integrate the customer more closely into the design and implemen- 
tation process? Extreme Programming is a functioning solution, but it does 
not scale. 

— Continuous process: how can we extend and improve the usability of the 
models and modelling techniques used for design and implementation so that 
they also become a practical means of reference for the (sometimes extremely 
long lived) expensive maintenance phases? This must happen so that these 
models become an accepted support rather than a burden in the continuous 
release evolution. 

~ Legacy systems: how can we deal with existing, “historically grown” sys- 
tems, which typically lack an underlying formal model? This aspect gains 
ever increasing importance as complex industrial systems typically depend 
on third party-subsystems, for which only APIs and user manuals are avail- 
able. Moreover, most industrial systems too soon become de facto legacy 
systems, since it is usually impossible to maintain and update the documen- 
tation and modelling of the development over the many release cycles. 



1.2 The Legacy Problem 

These problems are gaining increasingly vital importance, and they will reach 
be increasing criticality in the future. Some reasons are easily listed: 

— If the specification is wrong, the whole ongoing process of design, imple- 
mentation, release is deemed to eventually fail or, at least, the required 
adaptations become extremely expensive. Thus we need to be able to check 
specifications directly with the customers in order to validate their real re- 
quirements as early as possible. Unfortunately, use cases as found in UML 
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are not expressive and precise enough, and almost all available and suc- 
cessful formal modelling methods and languages (like e.g. Petri Nets, State 
Charts, SDL, MSCs or language like OCL and Z and tools like the B tool) 
are typically by far outside the skills of a customer. 

— Systems become increasingly complex, thus it is impossible for a single per- 
son to know all their details. Thus improved support by means of adequate 
models is needed, in order to capture and communicate all the required 
information on various levels of abstraction. More concretely, we need mod- 
elling tools that capture global aspects, and that support refinement, aspect- 
oriented concretization, and checking, as well as several ways of dealing with 
syntactic and semantic concepts of abstraction and hierarchy. This is partic- 
ularly crucial for the maintenance phase, where good models are ideal means 
for understanding the effects of upgrades or the localization of errors. 

— Modelling is needed in particular for already existing systems. Most systems 
in use today lack adequate specifications or make use of un(der)specified 
components. In fact, the much propagated component-based software design 
style naturally leads to produce under-specified systems, since most compo- 
nent specifications are quite partial. In these cases, global aspects need to be 
modelled on a higher level, which does not require implementation details. 
We may think e.g. about the software that implements real-time inter-bank 
money transfers: it requires the cooperation of middleware, operating sys- 
tems, databases, ERP systems and a huge number of specific software pack- 
ages in a significant number of banks in order for a payment to be effectuated 
correctly around the globe. In cases like this the global aspects should be 
specified on the component-coordination level, while suppressing as much 
detail about the involved components as possible. In fact, this global mod- 
elling should not even try to pinpoint errors within the various components, 
but rather concentrate on their interplay. 

To attack the problems above we propose an observation-based approach. This 
approach is characterized by its global perspective (observations are taken at the 
system level), by its view-based construction (models are constructed according 
to device or aspect-specific projections of the global behavior), and, perhaps 
most importantly, by its high potential for automation, that makes it particularly 
valuable for capturing the evolution of a system during its life cycle. 

In the following, after a brief overview of our approach (in Sect. 2), we sketch 
the contributions of this paper (Sect. 2.4), which in particular indicate its prac- 
ticality. We then present our application scenario in Section 3 and sketch the 
foundations of our approach in Section 4. The main discussion is entered in Sec- 
tion 5, which establishes our view-based approach for treating parameterized 
systems. Finally, we draw our conclusions in Section 6. 

2 System-Level Observation-Based Model Construction 

Our observation-based approach is intended to support the continuous-engineer- 
ing process along all the phases of a system’s life cycle. Its focus is therefore on 
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easy, user- level abstractions of the global system behavior, non-invasiveness of 
the technology, and sensitivity to the system changes during the life cycle. This 
lead to the following profile: 



2.1 (Semi-) Automatic Model Construction 

Using techniques from automata learning, combined with automata-theoretic 
and logic-based approaches, it is possible to extrapolate expressive models of 
legacy applications without any access to source code or formal specifications 
[6,5]. These extrapolated models are typically neither sound nor complete, but 
they serve as a powerful means for consistently presenting all the knowledge 
available about the system. Typically, this is used in practice to capture and 
communicate the user-level knowledge, which is on the one hand very abstract, 
but on the other hand the typical knowledge (still) available for legacy systems. 
This approach is ideal for accompanying the software life cycle or even steering 
the systems’ evolution, as the quality of the extrapolated behavioral models 
increases during the systems’ life cycle. As most of the model construction is 
automatic, extrapolated models can be kept up-to-date at very low cost. 



2.2 luterleaviug Learuiug aud the Use of Extrapolated Models 

Extrapolated behavioral models provide a solid basis for runtime monitoring, 
test generation, test coverage evaluation, test result analysis and, in fact, for 
automating large portions of regression testing. Taken together, these are the 
major cost factor for the release and maintenance of industrial systems. Besides 
profiting from the information captured in the model, model-based testing and 
monitoring of running systems (see e.g. Sect. 5) can also be regarded as a means 
to implement model evaluation: whenever an observation is in conflict with the 
extrapolated ‘hypothesis’ model, experts need to be consulted in order to decide 
whether the system or the model needs to be altered. Both, the system correc- 
tion, as well as the modification of the model along the observed discrepancy 
automatically improve the system/model relationship. Thus by design our ap- 
proach enhances and steers the software maintenance phase without imposing 
significant additional effort. 

Please note, however, that our approach addresses only the analysis of 
(legacy) systems. Their correction and evolution is an orthogonal matter and 
should be done by the corresponding responsible teams. 



2.3 Many Very Abstract, Aspect-Specific Modelings 

Adequate levels of abstraction make observations directly comprehensible for 
customers, both for validating the system requirements and for judging the im- 
pact of conceptual system changes [10]. In fact, various such levels are typically 
required in practice in order to capture different views onto the system, since e.g. 
different people get different projections of the overall behavior: the customer 
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needs the user view, the data security expert the corresponding protocol view, 
and the quality controller needs specific views that capture exception handling, 
warnings, and all kinds of potential misbehaviors. 

Using different abstraction mappings during our extrapolation procedure, we 
automatically obtain view-specific models of the global system. In our applica- 
tions these views reflected projections onto the context-specific behavior of de- 
vices (which can easily be identified at the protocol level) and device-overlapping 
aspects like payment or exception handling. More complicated are abstractions 
that project systems with n devices onto systems with a much smaller number 
of devices. The paper will focus on this scenario (see Sect. 5). 



2.4 Technical Contributions of This Paper 

As described above, the main characteristics of our approach are ensured by 
design. But how realistic is this design in practice? A proof of concept has been 
given directly on the basis of our integrated testing environment (ITE), which 
provides the technical means required during the extrapolation process, as well 
as for monitoring the running system. But does our approach scale? In this paper 
we discuss scalability in the context of parameterized systems. The considered 
setting stems from an industrial project (see Sect. 5), where the treatment of 
large numbers of devices in a distributed telecommunication system was of vital 
importance. 



3 Observing and Testing Distributed Systems 

Modern telecommunication and IP-based applications are multi-tiered, distri- 
buted applications that typically run on heterogeneous platforms. Their correct 
operation depends increasingly on the interoperability of single software modules, 
rather than on their intrinsic algorithmic correctness. A scalable, integrated test 
methodology capable of granting adequate coverage of functional testing, yet 
still easy to use has been presented in [12]. This methodology bases on our 
previous work on system level test of Computer Telephony Integrated (CTI) and 
Web-based applications, where we applied very successfully our coordination- 
based coarse grain approach to modelling and design of complex distributed 
systems [13]. 

To test complex cooperating systems of the kind shown in Fig. 1 we add a 
Test Coordinator to the system under test: the test coordinator is an indepen- 
dent system that drives the generation, execution, evaluation and management 
of the system-level tests in highly heterogeneous landscapes. This introduces 
the required fiexibilization of the overall architecture of the test environment: it 
leads to a modular and open environment, so that diverse test tools and units 
under test can be added at need. The Test Coordinator has access to all the 
involved subsystems and can manage the test execution through a coordination 
of different, heterogeneous test tools. These test tools, which locally monitor and 
steer the behavior of the software on the different clients/servers, are technically 
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Fig. 1. Overview of the system to be learned and its environment. 

treated just as additional units under test. The resulting test environment, called 
ITE (Integrated Test Environment [7]) has been successfully applied along real 
life examples of IP-based and telecommunication-based solutions: the test of a 
web-based application (the Online Conference Service, used e.g. for the support 
of the Program Committee operations of four ETAPS 2003 conferences) and 
the test of IP-based telephony scenarios (e.g. Siemens’ testing of the Deutsche 
Telekom’s Personal Call Manager application [11], which supports among other 
features the role based and web-based reconfiguration of virtual switches). In 
both cases, no fine grained formal model of any subsystem was available, but a 
rich collection of expressive test cases - adequate for applying our model gener- 
ation methodology - was available already a short time after the adoption of the 
ITE test environment. 

In this paper, we show the use of our model generation technique by applying 
it to the system from Fig. 1 which we briefly describe (details can be found in 
[6]). The system’s main part is a midrange telephone switch which is connected 
to the ISDN telephone network and acts as a ‘normal’ telephone switch to the 
phones. Additionally, the switch communicates directly via a LAN or indirectly 
via an application server with CTI applications that are executed on PCs. Here 
in essence two communication protocols are used: CorNet for the communication 
between the switch and its peripheral devices (phones), and CSTA/Tapi for the 
communication between the switch and the CTI client/server applications that 
communicate with the switch over LAN. Like the phones, the CTI applications 
are active components: they may stimulate the switch (e.g. initiate calls), and 
they also react to stimuli sent by the switch (e.g. notify incoming calls). 
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As just introduced in the general case, also in this concrete setting the tech- 
nical realization of the necessary interface to this System Under Test is provided 
by the integrated test environment ITE, and in particular it is coordinated by 
the Test Coordinator, which - among performing other functions - controls two 
different test tools, i.e. a test tool to control the telephone switch (Husim) and 
one for the interaction capabilities of the CTI application {Rational Robot)^. In 
our experiments [9] we have derived several models of the switch with the help 
of this interfacing machinery. 



4 Foundations of Model Extrapolation 

In this section, we sketch the cornerstones of our regular extrapolation approach 
to model construction. In particular, this comprises the concepts of abstraction, 
learning, and moderation. The following subsections address these issues using 
the previously described Computer Telephony Integrated (CTI) system (Fig. 1) 
for illustration. A more detailed account of these concepts can be found in [18]. 



4.1 Abstraction 

We use abstraction to reduce the models we want to construct to a manageable 
size. The main concern must be to achieve a level which retains useful infor- 
mation about the system while permitting automatic analysis and modification 
techniques to be applied. We chose to model on a propositional level, including 
relevant control aspects and causal dependencies of the system into the model 
while leaving out data and real-time aspects. This works particularly well for 
telephony systems, whose behavior usually does not depend on what is trans- 
mitted, but how, and which are rather loose in their timing constraints. 

Let us consider our example system which employs an instance of the Com- 
puter-Supported Telephony Applications (CSTA) protocol for some of its com- 
munications. A typical CSTA record contains several components. Some of them 
convey essential information relevant to the model, while others can be safely 
ignored. For most modelling purposes it will be sufficient to project such records 
to something as abstract as, for instance, 

(hookswitch0nHook,500) 

where hookswitchOnHook denotes the event that a telephone receiver has been 
replaced, and 500 identifies the phone device. 

This ‘hiding-based’ reduction is the first step towards a propositional view of 
a system’s behavior. However, more refined abstraction techniques are required 
for our approach to work in the considered scenario. 



^ This is described in more detail in [7]. 
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Event Separation. The systems operate in real time in an environment that 
exhibits much parallelism. For example, when observing a CTI system in op- 
eration, interactions belonging to different conversations will typically overlap. 
Permitting such interleavings in the model would obfuscate the really essential 
dependencies. Instead, we collect all the system’s reactions to each single stim- 
ulus by waiting until the system has reached a stable state. This is similar to 
the point of view taken in the synchronous systems approach [2,8], and it is also 
the approach typically taken as the basis for testing. In particular, it was the 
approach taken by our industrial partner. 

Based on this notion of event separation, we arrive at a view of a reactive system 
as an input/output transition system whose outputs are determined by previous 
inputs (an input- deterministic I/O transition system according to the following 
definition). It may also be assumed that the system is input enabled, i.e., that it 
accepts all inputs regardless of its internal state. 

Definition 1. 

An input/output transition system is a structure S = {S, Aj, sq), con- 

sisting of 

— a countable, non-empty set E of states, 

— countable sets Aj and Aq of input, resp. output, actions, 

— a transition relation -^C E x Aj x Aq x E, and 

— a unique start state sq. 

It is called input deterministic if at each state s there is at most one transition 
for each input starting from that state. It is input enabled if there is at least one 
transition for each input. 

Small Instantiations. Another property indispensable for our approach is the 
finiteness of the model. Usually, the number of components connected to a sys- 
tem like the telephone switch might be rather large, thus modelling a system with 
the maximal number of components (if known) would be impractical. Also, a 
new release might increase this parameter, thus invalidating the previous model. 
Such a large model would also not reveal much additional information about 
the system. In fact, both protocol specifications and practical tests usually work 
with small, finite instantiations of a system environment. We do the same, and 
thereby arrive at a manageable system size where address spaces can be repre- 
sented by few discrete symbols. In Section 5, which discusses the use of models 
for monitoring running systems, specific issues concerning the reduction to few 
components are presented. 

4.2 Learning 

Techniques from the field of automata learning were the guideline when im- 
plementing our regular extrapolation approach. Generally speaking, automata 
learning tries to construct an automaton matching the behavior of a given tar- 
get automaton based on observations of the target automaton and perhaps some 
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further information on its internal structure. We will not discuss the theory of 
learning here (the interested reader may refer to [18] for our view on and use of 
learning). Instead, we present the algorithm L* from [1], which we then adapt 
to fit our purposes. 

L* learns a finite automaton by posing membership and equivalence queries. 
A membership query tests whether a string is contained in the target’s language, 
and an equivalence test compares a hypothesis automaton with the target and, 
if they are not equivalent, it returns a string in the difference of the accepted 
languages. The basic idea behind L* is to systematically explore the system’s 
behavior using membership tests, and resorting to equivalence tests whenever no 
‘direct evidence’ for inconsistencies is available. On this basis, L* incrementally 
builds a minimal deterministic finite automaton (DFA) equivalent to the target, 
in a time which is polynomial in the size of the target and the counterexamples. 

Adapting L* to Our Scenario. In our scenario, we rely on being able to evaluate 
membership queries with our testing machinery (more on that later) . Equivalence 
queries are beyond practical realizability, but already [1] contained the result 
that by replacing precise equivalence tests by approximative sets of membership 
queries, L* can be turned into an algorithm which learns in an approximative 
sense: with high probability the learned automaton will accept a language very 
close to the given one, and this result will again be reached in polynomial time 
in the size of the target. We have adapted it in a different, but similar way 
[9] to arrive at an adequate approximate equivalence test based on membership 
queries. 

An interesting technical point is the fact that L* is constructed to learn 
DFAs that accept regular languages, whereas our scenarios are modelled best as 
(combinations of) I/O transition systems. The assumption of input determinism 
makes it possible to translate membership tests for certain strings to the appli- 
cation of input sequences to an I/O transition system. All further adaptations 
and optimizations become technicalities, though of sometimes major practical 
importance for the consumption and management of time and resources. 

Realizing Membership Tests. Membership queries can be answered by testing the 
system we want to learn. This is not easy, because the sequence to be tested is an 
abstract, propositional string, but the system is a physical entity whose interface 
follows a real-time protocol for the exchange of digital (non-propositional) data. 
Thus we have to drive the system with real data, which requires to reverse the 
abstraction and produce a concrete stimulation string. 

In practice, we need a concretization function where things once abstracted 
from the observations have to be filled in dynamically, taking the reactions of 
the system and consistency criteria into account. For instance, time stamps have 
to increase, and instead of symbolic addresses and symbolic tags their concrete 
counterparts have to be used consistently. Finally, these data must be trans- 
formed into communication signals and fed to the real system. 

In the case of our example telephone switch, all this is done via our test- 
ing environment, the already mentioned ITE. ITE performs these tasks using 
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specific hardware as well as predefined code blocks for generating stimuli and 
for capturing responses and glue code, which together solve the problems con- 
nected with generating, checking and identifying the non-propositional protocol 
elements. Thus much of the work of putting our approach into practice relies on 
the preexisting capabilities of the ITE system and on its diverse components. 

Realizing Equivalence Tests. Though there is no exact equivalence test (and in 
fact, our extrapolated models will only rarely be equivalent to the abstracted 
system in a strict sense), one can approximate such a test pretty well in practice: 
the basic idea is to scan the system in the vicinity of the explored part, looking 
for discrepancies from the expected behavior. 

One particularly good approximation is achieved by performing a test in the 
spirit of [3,19]. This test is based on first computing a set of stimuli sequences 
by which all states in the conjecture automaton can be distinguished. Then, 
each transition in the conjecture automaton is validated by checking that, after 
moving to its start state and then firing it, the outcome in the real system 
behaves as it should with respect to all relevant distinguishing sequences. This 
test has polynomial complexity in the size of the conjecture automaton. Another 
possibility lies in checking consistency within a fixed lookahead from all states. In 
the limit, by increasing the lookahead, this will rule out any uncertainty, though 
at the price of exponentially increasing complexity. 

Further substitutes of an equivalence tests are derived with the help of expert 
knowledge. We describe these in the following section on moderation, since they 
involve human interaction. 



4.3 Moderation 

Moderation is the process of matching automatically generated models and hu- 
man concepts about the system behavior, with the behavior of the real system, 
and resolving any discrepancies. 

System Constraints. One point of interaction consists in the evaluation of 
whether a tentative model produced by the learning algorithm is acceptable, 
i.e. deciding whether the equivalence check of L* is passed or fails. The adequate 
incorporation of expert knowledge requires formalization. Here, (linear) tempo- 
ral logic [4] serves to formulate specifications which limit the model from above. 
I.e., experts formulate properties which they believe to be true of the system, and 
extrapolation results should be limited by them. Temporal-logic model check- 
ing is employed to check adherence of the model to these constraints. Counter 
examples generated by the model checker in case of a violation are studied to 
pinpoint the source of the discrepancy. 

First, it is checked whether the counter example of the model (which is a 
trace of the model not consistent with a constraint) is also a counter example 
for the real target system. Two outcomes are possible: 
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1 . If the observed system behavior is consistent with the hypothesis automaton, 
a discrepancy between a constraint and the system has been detected. Thus 
either the system itself has an error, or the specification is wrong. This 
has to be resolved manually, i.e. by consulting experts for the system or 
the application domain. If the error can be attributed to the specification, 
its correction is easy: the specification is corrected (or dropped), and the 
learning process can continue. 

If it is a system error, we can report success in detecting a real problem as 
a side-effect of the model generation. In this case, the error in the system 
should be corrected and the model subsequently adapted accordingly. 

While the correction of the model is usually easy, the correction of the real 
system is not always immediate: especially in case of third-party/legacy com- 
ponents the error or discrepancy cannot be fixed directly, but must be re- 
ported to a different team or company that is in charge of maintaining the 
source code. 

2. If the observed behavior of the target system deviates from that predicted by 
the hypothesis automaton, this trace is a counter example as expected from 
an equivalence oracle during the learning process. The learning procedure 
automatically takes the appropriate actions to improve the hypothesis model. 

5 Treating Parameterized Systems 

Regular extrapolation has turned out to be particularly well suited for appli- 
cation in regression testing, where a previous version of the system is available 
as approximate reference. Learning the behavior of previous versions therefore 
allows a cost-effective and flexible testing of new versions (cf. [7]): rather than 
running the reference system and the new version in parallel while comparing 
their results, which requires 

— two complete test systems, 

— a (typically) bit-wise comparison of test results at the protocol level, and 

~ an expensive analysis of the detected discrepancies - which, to our experience 
are mostly false alarms due to the too tight way of comparison 

extrapolated models 

~ can easily run in parallel with the system under test, without requiring any 
specific hardware, 

— allow for a much more flexible notion of comparison, e.g. by accepting any 
equivalent interleaving of events within the distributed system as a match, 
and 

— drastically reduce the analysis of discrepancies, firstly, because the number 
of false alarms is significantly reduced, and secondly since the model will typ- 
ically provide certain diagnostic information (e.g. error and warning states). 

In the following, we will focus on learning concise models (in fact specific views) 
that capture parameterized systems of this kind. The ideas we present do not 
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exclusively apply to this situation: another very important area of application is 
e.g. system monitoring (also often called online testing), which requires exactly 
the same kind of models. It should, however, become clear that the structure 
of extrapolated models may significantly depend on the intended use, and that 
certain optimizations, like the ones presented here, cannot always be applied. 

Parametric Reference Systems 

We consider parametric systems consisting of a central component which is con- 
nected to a (parametric) number of structurally interchangeable peripheral com- 
ponents, and use A°° to denote the set of finite and infinite sequences over the 
alphabet A. In order to be able to focus on the essence, we will refrain from the 
technical details concerned with input/output transition systems. 

Definition 2 (Parametric System). A parametric system P{n) consists of 
n -I- 1 components Cq, . . . ,C„, where Ci, . . . ,Cn are called parametric. Given a 
finite set T of message denominators, T x {Ci, . . . , for some fc G N is the 
set of communication records^. The semantics |P] of a parametric system P is 
given in terms of a prefix-closed subset of the set of traces of the corresponding 
communication records (T x {Ci , . . . , C„}^)°°. 

For a parametric system P{n) and m < n let P{m) denote a system with 
|P(to)] = |P(n)] n (T X {Cl, . . . , Cm}^)°°, i.e. the set of traces of P(n) men- 
tioning only the components Ci , . . . , Cm ■ 

A parametric system P is called symmetric, if for each permutation p of 
|Ci,...,C„}, we have p(|P]) = |P], where p(|P]) is the obvious extension of 
p to sets of traces of communieation records. I.e., the semantics of P is closed 
under permutations. 

We use parametric systems to represent the behavior of systems, abstracted 
to a propositional level, where only the number of peripheral components (like 
telephones or clients) remains variable. Co corresponds to a central component 
(like the switch or a server) to which all the peripheral components are connected. 

Small Instance Views 

The point of our technique is to learn a model of a symmetric parametric sys- 
tem capturing its behavior for small instantiations {small instance view, and 
to use this view for testing and monitoring. More concretely, when learning a 
small instance of a system P{n), we build a model for P{m) for some m < n. 
This model has the specific form of a DFA accepting a prefix-closed language of 
potentially infinite strings. 

Definition 3 (m- Model). Let P{n) be a parametric system with traces over 
Tx{Ci,...,C„}^. For m < n, an m-model for P{n) is a DFA M ( or, explicitly, 
M{m))) with alphabet T x {Di,...,Dm}^ (called observation recordsj where 
all states except one are accepting and the non-accepting state is a sink. The 
language of M, denoted by |M], is the set of all finite and infinite alphabet 

^ k is the maximal number of identifiers occurring in a protocol message. 
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sequences labelling transitions on paths in M which start in its initial state and 
do not enter the non-accepting state. 

Let fi be the function that maps Ci to D^, for i = 1, . . . ,m. The model M{m) 
is correct iff p,{\P{m)J) = \M{rri)\. 

Learning M(m) is possible due to the active learning approach taken by L*, 
which can be directly steered according to the chosen set of components as long 
as it is possible to identify these components by observation. In our application 
scenario this information is fully available in the communication records. Thus, 
even though the system under test is really huge (it may consist of potentially 
hundreds of parametric components), the learning process focusses just on the 
part relevant for the considered small instance view. 

Assuming that the parametric system is symmetric, a correct model does 
indeed provide complete information about all traces with at most m involved 
parametric components: 

Proposition 1 (Symmetric Correctness). Let M{m) be a correct model for 
a symmetric, parametric system P{n). Then M{m) is itself symmetric and for 
all subsets CS = , . . . , of {Ci, . . . C„} and every one-to-one mapping 

V from CS to {Di , . . . , Dm} it holds that i^(|P(n)] flT x CS^) = L, the language 
of M (to) . 



Small Instance Views in Use 

To construct a monitor from a symmetric model, we equip the monitor with two 
state components to hold 

— the current state of the model, and 

— an assignment of identifiers of peripheral components of the system being 
observed to the component identifiers Di, . . . Dm within the model. 

This construction is the basis for matching the concrete traces of the system 
with traces of the model. 

Definition 4. Let M{m) be an m-model for a parametric system P{n). An ob- 
servation state is a pair {v, s) of a partial one-to-one mapping v from compo- 
nent identifier in the model {Di, . . . , Dm} to concrete components of the system 
{Cl, . . . Cn} and a state s of M . 

Let now v be extended to observation records in the straightforward way. A 
communication record c of P{n) is matched by a pair of observation states {v, s) 
and {C,s') if v' is an extension of v and there is a transition s .s' of M such 
that v'{b) = c. 

A trace r of P{n) can be matched by M if there is a sequence {i'i,Si) of 
observation states of the same length as t where 

— So is the initial state of M and vq is the empty mapping, and 

— for each i, the pair consisting of {vi, Si) and its successor matches the obser- 
vation record Ti . 
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If a model M is symmetric, the check whether a trace is matched can be done 
easily online: the mapping v is extended only if needed, the choice of the minimal 
possible extension is arbitrary due to symmetry, and once the extension is chosen 
there is at most one transition due to the determinism of M . 

Theorem 1 (Correct Matching). A model M{m) of a symmetric parametric 
system P{m) is correct if and only if the set of traces matched by M{m) is the 
subset of traces in |^’(n)] where at most m parametric components appear. 

Thus correct small instance views (m-models) mimic the system under test per- 
fectly well as long as the number of components encountered is smaller than 
m. 

Small Instance Views: Where to Go 

The ultimate goal of our approach is to make it effective as long as the number of 
components being concurrently active in the system under test does not exceed 
the number modelled in the small instance view. 

Example 

Between independent usages, a phone typically returns to its initial state, at 
which it is indistinguishable from the behavioral point of view from all the other 
inactive phones. This offers the possibility to change the matching between inac- 
tive concrete components on demand, and therefore to increase the monitoring 
power of a parametric model M (m ) , in order to capture all traces where no more 
than m phones are active at the same time. 

This ‘dynamic scheduling’ of symbolic components requires the identification 
of those points, where one concrete device (e.g., phone) can be exchanged by 
another, which is difficult just on the basis of observations. For our application 
this boils down to decide at the model level that a component (phone) is inactive, 
resp. is in its initial state. 

Assuming that our model is correct, we have a criterion at hand: a component 
Di can be considered to be inactive in a state s of a model, if s is reachable in M 
from the initial state without taking any transition mentioning Di. This directly 
leads to the following definition: 

Definition 5 (Activity of Components). Let s be a state in a model M{m) 
of a parametric system P{n). A component D{i) is said to be inactive in s, if 
there exists a path from sq to s s.t. Di does not occur in any transition label on 
the path. Otherwise, the component is said to be active in s. 

Basing the notion of matching on active components only, we straightforwardly 
arrive at the following notion of liberal matching. 

Definition 6 (Liberal Matching). An communication record c of P{n) is 
liberally matched by a pair of observation states {v, s) and {v' , s') if v' is an 
extension of the restriction of v to the components active in s, and there is a 
transition s \ s' of M s.t. v'{b) = c. 
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A trace is liberally matched if there is a liberal matching sequence of obser- 
vation states. 

Obviously, the set of traces liberally matched can be much larger than the set 
of (strictly) matched traces. Therefore, monitors constructed accordingly will 
be able to follow the behavior of an observed system much longer and, to our 
experience, very accurately. Unfortunately, as will be explained in the next sub- 
section, our formal conditions are not sufficient to justify the generalization of 
Theorem 1 from matching to liberal matching. 



Limitations of Liberal Matching 

The reason for the failure of the generalization of Theorem 1 from matching to 
liberal matching lies in the fact that the central component may, in principle, 
behave history dependently in arbitrary way, as e.g. in the following situation: 

Consider a system P(8) which, whenever three different peripheral units have 
tried one specific action (and have been denied permission to perform it), will 
enable that action. A correct model M(2) will never permit that action, because 
it will never encounter a situation where three different peripheral units have 
tried this specific action. This does not change when moving to liberal matching 
mode. Thus the according monitor will remain too strict. 

Similarly, in the dual situation, where an action is prohibited after some 
history, the according monitor may be too loose. Thus none of the implications 
of Theorem 1 can be established in this more general setting. Still, as discussed 
in the final section, this does not affect our overall goal, which is anyway bound 
to deal with the ‘vagueness’ of hypothesis models. 

6 Conclusion and Perspectives 

We have presented an approach for view-based model construction, which aims 
at empowering moderated extrapolation [6] as a strong means to support the 
development, construction and maintenance of complex industrial systems. This 
approach is characterized by its global perspective (observations are taken at the 
system level), its view-based construction (models are constructed according to 
device or aspect-specific projections of the global behavior), and, perhaps most 
importantly, by its high potential for automation. Its focus on easy, user-level 
abstractions of the global system behavior, non-invasiveness of the technology, 
and sensitivity to the system changes makes it particularly valuable for capturing 
the evolution of a system during its life cycle. 

In order to judge the practicality and in particular the scalability of this 
approach, we have looked at particular views of parametric systems. These so- 
called small instance views are obtained from the global system by observing 
only very few of the parametric components, say n. It turned out that the small 
instance views are sufficient to fully capture the behavior of the global system 
as long as no more than n components have become active. 
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Simple examples unfortunately revealed that this result cannot be general- 
ized to capturing the full system as long as the number of concurrently active 
components is smaller than n. This observation, although sad from the theo- 
retical point of view, is characteristic for our regular extrapolation approach: in 
practice, we will typically never arrive at a sound or complete model, but the 
model will successively reflect more and more properties, and increase its value 
for its various applications. In fact, in practice, liberal matching wrt. the learned 
models turned out to be much superior to ‘precise’ matching. 

This more liberal approach to modelling very much resembles the approach 
proposed by [14], where observation-based ‘guess-work’ about invariants is pro- 
posed to the users in order to help them understand their programs better. 

As a case study, we have looked at a complex CTI system, in order to show a 
pragmatic approach for dealing with parametric systems. Here it is important to 
And the right compromise in the precision/cost trade-off. Accepted are typically 
all low cost means that provide serious warnings or error messages: a system that 
detects only 50% of the errors, but with a 90% hit rate (only 10% false alarms) 
is in practice much preferred over a system that covers 90% of the errors with a 
hit rate of 10 %. The latter systems are typically disabled after the treatment of 
a few false alarms. We are convinced that our pragmatic integration of formal 
methods into industrial practice will give the formal methods approaches a strong 
push, because it enables practitioners to feel the power of the techniques without 
suffering from too much pain. We observed this already in the application to the 
treatment of legacy systems: there the pain is often so strong that users are 
grateful for new alternatives. 

The first practical results are very encouraging, but there is still a long way to 
go until our approach can be used in the large. This concerns enhancing the au- 
tomation, optimizing the learning procedure, investigating the frame conditions 
for certain application-specific optimizations [9], improving the way to integrate 
expert knowledge into the model construction process, and concisely represent- 
ing large models. This requires a lot of theoretical and conceptual work, which, 
however, should be based on empirical results in order to guarantee its practical 
impact. 
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Abstract. Many software projects are based on the integration of inde- 
pendently designed software components that are acquired on the market 
rather than developed within the project itself. This type of components 
is well known as COTS (Commercial-Off-The-Shelf) components. Nowa- 
days component based technologies provide interoperability and compo- 
sition mechanisms that cannot solve the COTS components assembly 
problem in an automatic way. One of the main problems in components 
assembly is related to the ability to establish properties on the assem- 
bly code by only assuming a limited knowledge of the single components 
properties. Our answer to this problem is a software architecture based 
approach in which the software architecture imposed on the assembly, 
allows for detection and recovery of COTS integration anomalies. We 
build applications by assuming a defined architectural style. Then, we 
compose a system in such a way that it is possible to check whether 
and why the system presents some software anomalies (e.g.: deadlock, 
livelock). Depending on the kind of failures a recovery policy which can 
avoid the anomalies and obtain a correct assembly can be performed. A 
tool can then synthesize the assembly code (as a failures-free connector 
component) to glue together a set of COTS components. This glue code 
must be synthesized in such a way that (a well defined set of) functional 
properties required for the composed system are automatically guaran- 
teed. In the paper we briefly describe our approach and then we present 
its application to an example. 



1 Introduction 

Many software projects are based on the integration of independently designed 
software components that are acquired on the market rather than developed 
within the project itself. This type of components is well known as COTS 
(Commercial-Off-The-Shelf) components. One of the main problems in assem- 
bling COTS components is related to the ability to establish properties on the 
assembly code by only assuming a limited knowledge of the single components 
properties. Our answer to this problem is a software architecture based approach 
in which the software architecture imposed on the assembly, allows for detec- 
tion and recovery of COTS integration anomalies. Notably, in the context of 
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component based concurrent systems, COTS components integration may cause 
deadlocks or other software anomalies within the system [18,1,12,13]. The use 
of COTS components in system construction presents new challenges to system 
architects and designers [14] . Building a system from a set of COTS components 
introduces a set of problems. Many of these problems arise because of the nature 
of COTS components. They are truly black-box and developers have no method 
of looking inside the box. This limit is coupled with an insufficient behavioral 
specification of the component which does not allow to understand the com- 
ponent interaction behavior. Component assembling can result in architectural 
mismatches when trying to integrate components with incompatible interaction 
behavior [3] . Thus if we want to assure that a component based system validates 
specified behavioral properties, we must take into account the component in- 
teraction behavior. In this context, the notion of software architecture assumes 
a key role since it represents the reference skeleton used to compose compo- 
nents and let them interact. In the software architecture domain, the interaction 
among the components is represented by the notion of software connector. 

Our aim is to analyze and fix dynamic behavioral problems that can arise 
from components composition. We propose an architectural connector-based ap- 
proach [8,10,9]. The idea is to build applications by assuming a defined archi- 
tectural style, namely a modified version of the C2 architectural style [15]. We 
compose a system in such a way that it is possible to check whether and why the 
system presents some software anomalies (e.g.: deadlock). We can then derive, 
in an automatic way, directly from the COTS (black-box) components, the code 
that implements a new component to insert in the composed system. This new 
component implements an explicit software connector. This code is derived in 
such a way that the functional properties of the composed system are satisfied. 
We assume that a behavioral specification of the composed system is available. 
This specification is provided through Message Sequence Chart (MSC) and High 
Level MSC (HMSC) specifications [21,20,22]. Moreover we also assume that a 
precise definition of the properties to satisfy exists through LTL {Linear-time 
Temporal Logic) formulas definition [2, 6, 4, 5]. 

The paper is organized as follows. In Section 2 we introduce the problem we 
want to address and some background. Section 3 presents the technique to allow 
failures-free connectors synthesis [11] which is then applied in Section 4 on an 
example. Section 5 concludes. 

2 Problem Description 

We consider COTS components which are truly black-box components. The 
properties we want to check are functional properties as deadlock-freeness or 
general safety and liveness properties which describe expected behaviors of the 
system. The assembly A depends on the constraints induced by the architectural 
model the system is based on. The present architectural model, which defines 
the rules used to build the composed, is a modified version of the C2 architec- 
tural style. This modified version of C2 architectural style is called CBA (i.e. 
Connector Based Architecture) style and it is described in detail in [11]. 
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Fig. 1. Tool Architecture for the Automatic Failures-free Connector Synthesis. 



It is important to notice that, besides assuming that the system architec- 
ture must reflect the rules of a well defined architectural style, we also assume 
that a system behavioral specification is provided through message sequence 
chart (MSC) and High level MSC (HMSC) specifications. Then we can derive, 
in an automatic way, from the MSC and HMSC specification, the behavioral 
description of each component in the composed system. This behavioral descrip- 
tion can be derived by suitable applying the algorithm described in [21,20,22]. 
Each component behavioral description take a form of graph. Informally our 
approach is the following. The method starts off a set of components, and builds 
a connector following the reference style constraints. Components are enriched 
with additional information on their dynamic behavior which takes the form of 
graphs. Then property analysis is performed. If the synthesized connector con- 
tains property violating behaviors, a recovery policy is applied. Depending on 
the kind of property, the analysis of only the connector is enough to obtain a 
property-satisfying version of the system. Otherwise, the property is due to some 
component internal behavior and cannot be fixed without directly operating on 
the component code. In a component based setting in which we are assuming 
black-boxes components this is the best we can expect to do. 

3 Connector Synthesis 

Our goal is to develop a tool that performs an automatic software connector 
synthesis. The aim of this synthesis process is to derive the glue code for the 
components that constitute the composed system. The glue code is automati- 
cally synthesized directly from the partial specification of the composed system 
(MSCs and HMSC). The composed system automatically synthesized must sat- 
isfy the behavioral properties expected from the system designers and architects. 
In Figure 1 we illustrate the automatic synthesis tool architecture. 
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We represent with labelled boxes the components of the synthesis tool and 
with the labels the input and output data for each functional component of 
the tool. We have represented with the labels followed by a gray bold arrow 
intermediate data that are necessary to perform some transformations on the 
output data of the “From (H)MSC to LTS Translator” component. We perform 
these transformations in order to obtain the input data for the “Unification 
Algorithm” component. The gray bold arrows represent these transformations. 

We model components as labelled transition systems (LTS) where labels rep- 
resent messages that the components can input and output on the communi- 
cation channel. We consider the system as a parallel composition of all com- 
ponents. In literature many approaches to build, in an automatic way, an LTS 
from an MSC specification exist; we are entirely based on the approach described 
in [21,20,22]. We adapt these algorithms to build the actual behavior graph (AC- 
Graph) [8,10,9] of the system components directly from the MSC specifications. 
A formal definition of AC-Graph is in [8]. Informally we can say that an AC- 
Graph for a component C describes the interaction behavior of C with its ex- 
ternal environment. This environment is modelled as the parallel composition of 
all the others components in the system. We wish to derive from a component 
behavior the requirements on its environment that guarantee deadlock-freedom. 
From the AC-Graphs we can automatically derive the corresponding AS (AS”- 
sumption) graphs. The AS-Graph is different from the corresponding AC-Graph 
only in the arcs labels. Actually these labels are symmetric since they model the 
deadlock-free environment as each component expects it. This is true because we 
assume synchronous communication between components of the system. Given 
the CBA style [8], the component environment can only be represented by one 
or more connectors, thus we refine the definition of AS-Graph into a new graph, 
the EX-Graph, that represents the behavior that the component expects from 
the connector. Each component EX-Graph represents a partial view of the con- 
nector expected behavior. It is partial since it only reflects the expectations of a 
single component. Actually in the EX-Graph of a component C we have actions 
on a communication channel that is unknown for C and actions on a communi- 
cation channel that links C with the connector. The global connector behavior 
will be derived by taking into account all the EX-graphs. This will be done 
through a sort of unification algorithm [8] . The role of the connector is to route 
every component request to the request receiver component. Then it returns 
the request response to the component which fired the request. We automati- 
cally synthesize a model of the behavior of the connector which contains all the 
possible request routing policies. Then we perform analysis of properties and re- 
covery. This means that we could allow a designer to assign a precise scheduling 
policy to the connector. Referring to the usual model checking approach [2,7], 
we can think of defining the properties that the system must satisfy by using 
Linear-time Temporal Logic (LTL) formulas [6,4,5]. We can specify the set P 
of properties that describe the expected behaviors of the system. The synthesis 
tool uses the set of properties P to identify connector graph portions that do 
not satisfy the requested routing policy. Therefore every property in P is used 
to check if the connector contains an unexpected behavior. For each property 
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Pi G P the synthesis tool derives the Biichi Automaton [2,6,4] BAi correspond- 
ing to the LTL formula Ipi, where the symbol ! is the logical negation operator. 
Then the tool verifies if in the connector graph a (possibly infinite) arc labels 
sequence t (an execution trace) exists in such a way that an accepting execution 
of BAi on the word corresponding to t exists. We have explained formally this 
test in [11]. Informally, an execution trace t on the connector graph represents 
a connector behavior that satisfies the negation of the property pi, thus it rep- 
resents an unexpected behavior of the connector. At this point the tool could 
apply two possible recovery strategies to guarantee the desired behavior: i) It 
does not modify the connector semantics or ii) it modifies the connector seman- 
tics. In the first case the tool, in the code derivation step, considers the connector 
graph portions marked as unexpected behavior, as exceptional running traces. 
Thus it derives for them a code that implements an exception handling block. 
In the second case the tool simply cuts the connector graph portions marked as 
unexpected behavior. Thus the code derivation step does not implement these 
unexpected running traces. Finally the synthesis tool verifies if the connector en- 
sures the expected behavior for all components connected to it. In this last step 
the tool compares any AS-Graph with a corresponding connector graph portion 
by using a sort of state-based equivalence (CB-Simulation) [8]. After we have 
obtained the connector graph that satisfies a particular routing policy, the tool 
automatically derives the code of a new component, the connector component, 
to insert in the composed system. This new component routes the requests of 
the components connected to it in such a way that, by construction, the com- 
posed system behaves as required. It is important to notice, in Figure I, that 
every LTS corresponding to a component is expressed by using a data struc- 
ture that takes the form of automata (the AC-Graph). We can give a textual 
representation for each AG-Graph by using a process algebra specification (e.g. 
Calculus of Communicating Systems (GGS) [16]). The following are the steps of 
the algorithm used to build the failures-free connector graph and to derive the 
failures-free assembly code: 

1. let iF be the connector to build; 

2. FOR EAGH component Ci build the EX-Graph EXi for Cp, 

3. IF it is impossible to unify all the EX-Graphs EXi THEN exit{F AI LU RE) 
ELSE unify all the EX-Graphs EXi and put in K the EX-Graphs unification 
result; 

4. FOR EAGH property pi in the set P of properties to be validated, build the 
Biichi Automaton BA\p^ for the logical negation of pi] 

5. IF a Connector Craph Execution Trace tj exists (in K) in such a way that 
an accepting execution of BAtp. on tj exists, THEN mark the trace tj for 
all j; 

6. remove from K all the paths that contain a marked Connector Craph Exe- 
cution Trace; 

7. FOR EAGH component Ci IF CBSimulation{ASi, CBi) does not success- 
fully terminate THEN exit{E AI LU RE) ELSE derive from K the assembly 
code implementation; 

8. exit{SUCCESS); 
where: 
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ASi is the AS-Graph of the component Ci which is connected to the connec- 
tor; CBi is the CB-Graph [11] for Ci. This graph represents the portion of the 
connector graph that communicates with the component Ci. 

CBSimulation{ASi,CBi) successfully terminates if the expected behavior 
of the environment for the component Ci (ASi) is GB-simulated [11] from the 
portion of the connector behavior regarding the communication with a given 
component (Ci). C B Simulation{ASi, CBi) is performed by not considering the 
expected environment behaviors (paths of corresponding to execution paths 
in BA\p.. Informally CB-Simulation is a notion of simulation based on stuttering 
equivalence [17]. 

4 Example: The Dining Philosophers 

This example is an instance of the well known Dining Philosophers problem [19] 
in which we consider two philosophers and two forks. We present the component 
structure of the dining philosophers problem in Figure 2. 




Fig. 2. Architectural View of the Dining Philosophers Problem. 



There are 4 components: i) the first fork (Forkl), ii) the second fork (Fork2), 
iii) the first philosopher (Philosopherl), and iv) the second philosopher (Philo- 
sopher2). The forks components can iteratively wait for a request, give the 
fork, and then wait for the fork to be released. The philosophers can non- 
deterministically choose to ask for a fork, get it, then ask for the other, eat 
and then release the forks. Since a philosopher to eat needs both the forks it 
is obvious that in the following scenario a deadlock could arise: 1) component 
Philosopherl requests and gets the resource of component Forkl; 2) component 
Philosopher2 requests and gets the resource of component Fork2; 3) component 
Philosopherl requests and waits for the resource of component Fork2; 4) com- 
ponent Philosopher2 requests and waits for the resource of component Forkl. In 
this scenario Philosopherl is waiting for Fork2 release. Since Philosopher2 gets 
the resource of Fork2, this event can be caused only by Philosopher2 who is wait- 
ing for Forkl release. Since Philosopherl gets the resource of Forkl, this event 
can be caused only by Philosopherl. Thus each system component is waiting for 
an event that only another system component can cause. It means a deadlock. 



190 



Paola Inverardi and Massimo Tivoli 




Fig. 3. Architectural View of the Connector-based Dining Philosophers Problem. 
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Fig. 4. Basic MSC specification of the composed system. 



Now we present the connector based component structure of the dining 
philosophers problem in Figure 3. The role of the connector is to route every com- 
ponent request to the request receiver component. Then it returns the request 
response to the component which fired the request. Through the routing policy 
it implements, the connector can decide to accept or to reject a specific request. 
Suppose that we can benefit of the behavioral specification of the composed 
system given in Figures 4 and 5 as MSC and HMSC specification respectively. 

By applying the MSC to LTS translation algorithm described in [11], and 
based on an our purpose adapted version of the algorithm described in [21,20,22], 
we can obtain the AC-Graphs for each component in the composed system 
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Fig. 5. High Level MSC specihcation of the composed system. 





AC-Graph of the components Philosopherl and Philosopher2 



Fig. 6. AC-Graphs of the Dining Philosophers components. 



{Forkl, Fork2, Philosopherl and Philosopher2). We show these AC-Graphs 
in Figure 6. 

From these graphs we derive the AS-Graphs showed in Figure 7 and from 
the AS-Graphs we derive the EX-graphs in Figure 8. From the EX-Graphs by 
applying the unification algorithm described in Section 3 we can obtain the 
connector graph illustrated in Figure 9. 

As showed in Figure 9, we automatically synthesize a model of the behavior 
of the connector which contains all the possible request routing policies. Then we 
perform analysis of deadlocks and recovery. The deadlocks analysis step consists 
of searching for stop nodes in the connector behavioral graph. These nodes rep- 
resent states in which the system does not perform any action. Thus stop nodes 
represent deadlock states. The deadlocks recovery step consists of cutting the 
connector graph branches that lead to stop nodes. In Figure 11 we have showed 
the deadlock- free connector graph. 

It is worthwhile noticing that before the possible deadlocks are fixed the 
connector contains all possible composed system behaviors. This means that it 
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Fig. 7. AS-Graphs of the Dining Philosophers Components. 
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Fig. 8. EX-Graphs of the Dining Philosophers Components. 




Fig. 9. Automatically Synthesized Connector. 
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contains all possible routing policies. A designer can now think not only of a 
deadlock-free routing policy but of a precise scheduling one. For instance he 
might want the philosophers to eat in turn or that the Philosopherl always eats 
twice before Philosopher2. This means that we could allow a designer to assign 
a precise scheduling policy to the connector. Suppose that the composed system 
designer has specified the following properties: 

- PROPERTY 1: 

LPi= []((Ofelc A Ok2c) — *■ X([]{\(Oklc A Ok2c)))); 

- PROPERTY 2: 

LP2= []{{OklD A Ofc2o) — *■ X{i]{\{OklD A Ofc2r,)))). 

With these two properties, the system designer specifies two expected system 
behaviors that have been specified to avoid this two possible scenarios: i) the 
first philosopher eats and the second philosopher waits for the forks forever and 
ii) the second philosopher eats and the first philosopher waits for the forks for- 
ever. These two conditions are important for the progress of the system because 
they implies that both the two philosophers eat an equal number of times. More 
exactly for equal number of times we means the same number of times in quan- 
tity order. By satisfying LPi and LP 2 the connector can avoid the starvation. 
For example with LPi the user specifies that for all executions (in the connector 
model that we are considering), in which the first philosopher has requested and 
obtained both the two forks then it will have to be always true that the first 
philosopher does not obtain both the two forks again. Analogously for LP 2 - 

To limit the size of the paper, we describe the behavioral properties analysis 
step only for the property LPi . The following approach is completely equivalent 
for LP 2 - We derive, in an automatic way, a suitable form of the Biichi Automaton 
corresponding to the property \LPi in order to search, in the graph of 
Figure 11, Connector Graph Execution Traces tj in such a way that an accepting 
execution of BA\pp^ on tj exists. In Figure 10 we have illustrated the Biichi 
Automaton, corresponding to \LP\. 

The reader, by looking the Figure 11, can easily see that there are infi- 
nite Connector Graph Execution Traces tj, corresponding to the two paths 
LPl_Failurel and LP 1 _Failure2 in Figure 11 respectively, in such a way that 
an accepting execution of BA\pp^ on tj exists. This means that the deadlock-free 
connector model satisfies the LTL formula \LPi since there is at least one execu- 
tion trace in which only the first philosopher requests and obtains the two forks 
and the second one waits for the forks forever. Thus the derived deadlock-free 
connector model is a really deadlock-free model of the connector but it does not 
guarantee the progress of the system. 

4.1 Behavioral Failures Recovery 

After we have performed the behavioral failures analysis step, we can have pos- 
sible traces or paths in the connector graph in which the properties are not 
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!LP, = !([]((Ok1pA Ok2^ ) -> X([](!(Ok1cA Ok2c))))) 




Fig. 10. Equivalent Biichi Automata corresponding to LTL property \LPi. 



satisfied (behavioral failures). We propose a strategy based on the elimination 
of all the paths, in the connector graph, in which we have found a Connec- 
tor Graph Execution Trace accepted by the Biichi Automaton BA\lp^. Then, 
for every component Ci, we checked if its AS-Graph ASi is simulated by the 
CB-Graph CBi of Ci under the notion of GB-Simulation. We have seen, by per- 
forming the analysis step on properties LPi and LP 2 , that there are two paths, 
in the deadlock-free connector graph, in which the property LP\ is not satisfied 
and there are others two paths in which LP 2 is not satisfied. In Figure 11 we 
have represented this four paths by coloring gray the nodes in the paths. 

We have called the two paths that not satisfy the property LPi as 
LPl_Failurel and LPl_Failure2 respectively and the two paths that not 
satisfy the property LP 2 as LP2 Failurel and LP2 Failure2 respectively. By 
cutting those paths from the connector graph we obtain the Deadlock-Free and 
Progress-Satisfying Connector Graph of Figure 12. 

By the Figure 12, we can see that this model of the connector forces the 
two philosophers to eat in an alternate way. This is true because every time the 
first philosopher eats then necessarily the second philosophers will eat too and 
viceversa. This implies that this model of the connector satisfies the properties 
LPi and LP 2 - The reader can easy verifies that for every component Ci the GB- 
Graph CBi (of the connector graph of Figure 12) for Q simulates the AS-Graph 
ASi under the notion of GB-Simulation^. 

5 Conclusions and Future Works 

In this paper we have presented an example of application of our approach to 
compose a system out of a set of black-box components in a behavioral failures- 
free way. A key feature of the approach is that the system architecture follows 



^ Except for the paths of ASi that are also execution paths of BA\lp^- 
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Fig. 11. Deadlock-Free Connector Graph not-satisfying the properties LPi and LP 2 - 




Fig. 12. Deadlock-Free and Progress-Satisfying Connector Graph. 



a precise architectural style; this makes the automatic synthesis of connectors 
possible. Furthermore, the fact that it is known how the components will inter- 
act through the connectors makes behavioral failures analysis and/or recovery 
possible. The approach thus exploits the knowledge of the system architecture in 
order to improve the quality of the resulting system with respect to architectural 
mismatches. 

As far as complexity is concerned, our approach, contrary to [12], does not 
improve standard analysis techniques. From this point of view our method shares 
the same problems of the techniques based on analysis performed on the global 
system behavioral model. The added-value of our method is the ability to gen- 
erate a failures-free system, by automatically synthesizing a safe connector. 
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At present we have applied the approach in a real scale context, namely in 
the context of COM/DCOM applications [9]. At a very high level of descrip- 
tion, what has been done is to recast the notions and techniques introduced 
in the paper in the COM/DCOM context by suitably extending the IDL in 
order to accommodate our notion of AC-graph in the component interface de- 
scription. Then the application is build according to the CBA style by letting 
a COM/DCOM server to act as the synthesized connector. Behavioral failures 
freedom is then checked by following our definitions. To our respect, it showed 
the feasibility of our approach and its applicability in commercial component 
based contexts. As far as components are concerned we only assumed to have 
a description of the composed system behavior by means of MSCs, which is, in 
our view, an acceptable hypothesis. 

In [10] we mentioned that our method can be applied to multi-layered sys- 
tems as well. When more than two layers are considered we have to split AS- 
Graphs according to the two component domains top and bottom. From these 
we can generate the corresponding pairs of expected graphs which should then 
be unified. The unification algorithm must be slightly modified to cope with 
this extension. Our method can have better state complexity results in a layered 
system, since the connector corresponding to each layer must only consider the 
subset of components that interact with it. 

References 

1. B. Boehm and C. Abts. Cots integration: Plug and pray? IEEE Computer, 32(1), 
Jan. 1999. 

2. O. G. Edmund M. Clarke, Jr. and D. A. Peled. Model Cheeking. The MIT Press, 
Cambridge, Massachusetts, London, England, 2001. 

3. D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is so 
hard. IEEE Software, 12(6), Nov. 1995. 

4. P. Gastin and D. Oddoux. Fast Itl to buchi automata translation, in Proceedings 
of CAV’Ol, 2001. 

5. R. Gerth, D. Peled, M. Y. Vardi, and P. Wolper. Simple on-the-fly automatic 
verification of liner temporal logic, in Proc. of the 15th IPIP/WC6.1 Symposium 
on Protocol Specification, Testing and Verification (PSTV’95), 1995. 

6. D. Giannakopoulou and K. Havelund. Automata-based verification of temporal 
properties on running programs. RIACS Technical Report 01.21, 2001. 

7. D. Giannakopoulou, J. Kramer, and S. Cheung. Behaviour analysis of distributed 
systems using the tracta approach. Journal of Automated Software Engineering, 
special issue on Automated Analysis of Software, 6(l):7-35, January 1999. 

8. P. Inverardi and S. Scriboni. Connectors syntesis for deadlock-free component 
based architectures. 16th ASE, Coronado Island, California, November 2001. 

9. P. Inverardi and M. Tivoli. Automatic synthesis of deadlock free connectors for 
com/dcom applications. In ACM Proceedings of the joint 8th ESEC and 9th ESE, 
ACM Press, Vienna, Sep 2001. 

10. P. Inverardi and M. Tivoli. Deadlock-free software architectures for com/dcom 
applications, to appear on Elsevier Journal of Systems and Software Special Issue 
on Component-based Software Engineering, Nov. 2001. 




Automatic Failures-Free Connector Synthesis: An Example 197 



11. P. Inverardi and M. Tivoli. Connectors synthesis for failures-free component based 
architectures. Technical Report, University of L’Aquila, Department of Computer 
Science, http://www.di.univaq.it/tivoli/ffsynthesis.ps, ITALY, August 2002. 

12. P. Inverardi and S. Uchitel. Proving deadlock freedom in component-based pro- 
gramming. Proceed. EASE 2001, LNCS 2029 pp. 60-75, April 2001. 

13. N. Kaveh and W. Emmerich. Deadlock detection in distributed object system. 8th 
FSE/ESEC, Vienna, September 2001. 

14. D. Mark, R. Vigder, and J. Dean. An architectural approach to building systems 
from cots software components. National Research Council Report Number 40221. 

15. N. Medvidovic, P. Oreizy, and R. N. Taylor. Reuse of off-the-shelf components 
in c2-style architectures. In In Proceedings of the 1997 Symposium on Software 
Reusability and Proceedings of the 1997 International Conference on Software En- 
gineering, May 1997. 

16. R. Milner. Communication and Concurrency. Prentice Hall, New York, 1989. 

17. R. D. Nicola and E. Vaandrager. Three logics for branching bisimulation. Journal 
of the ACM, 42(2):458-487, 1995. 

18. C. Szyperski. Component Software. Beyond Object Oriented Programming. Addi- 
son Wesley, Harlow, England, 1998. 

19. A. S. Tanenbaum. Modern Operating Systems. Prentice Hall Inc., 1992. 

20. S. Uchitel and J. Kramer. A workbench for synthesising behaviour models from 
scenarios. In in proceeding of the 23rd IEEE International Conference on Software 
Engineering (ICSE’Ol), Toronto, Canada. May 2001. 

21. S. Uchitel, J. Kramer, and J. Magee. Detecting implied scenarios in message 
sequence chart specihcations. In ACM Proceedings of the joint 8th ESEC and 9th 
FSE, ACM Press, Vienna, Sep 2001. 

22. S. Uchitel, J. Kramer, and J. Magee. From sequence diagrams to behaviour mod- 
els. In In WTUML: Workshop on Transformations in UML. Satellite event of the 
European Joint Conferences on Theory and and Practice of Software (ETAPS’Ol), 
Genova, Italy. April 2001. 




Module Dependences in Software Design 



Daniel Jackson 



MIT Lab for Computer Science 
200 Technology Square 
Cambridge, Massachusetts 02139 
dnjOmit . edu 



Abstract. A new model of inter-module dependences is proposed. The 
key idea is that dependences are mediated by specifications, so that not 
only the existence of a dependence is recorded, but also its quality. A 
single module does not necessarily offer only a single specification; each 
dependent module may use it through a different specification. This no- 
tion of dependence seems to explain some common programming idioms 
more readily than the conventional notion, and offers new opportunities 
for analysis and design critique. 



1 Introduction 

Software designers have long recognized the significance of dependences between 
modules in evaluating a design. When modules have many interdependences, the 
system is harder to understand; there is less flexibility to divide the labour of 
coding; and local changes have wide repercussions. But despite the seminal role 
of dependences, most designers have only a fuzzy sense of what they are and 
how to express them. 

Although various kinds of code dependences have been heavily investigated 
because of their role in separate compilation and program analysis, much less 
attention has been paid to design dependences. As a result, dependence diagrams 
are much less useful than they might be in program design, and cannot be used 
as a basis for analysis. 

This paper outlines a new dependence model. Work on the model is in its 
preliminary stages, but it does seem to resolve some of the problems of the 
standard model, and in particular accounts better for some common idioms in 
object-oriented designs. 

2 The Standard Model and Its Deficiencies 

The standard notion of module dependence, first articulated by Parnas [8], is 
familiar to most developers. The system is described as a graph whose nodes 
represent modules and whose edges represent syntactic dependences. A depen- 
dence of module A on module B, drawn as an arrow from A to B, says that A, 
in providing services to the modules that depend on it, makes use of B. More 
precisely, A depends on B or uses B if “correct execution of B may be necessary 
for A to complete the task described in its specification” [8]. 
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In teaching software engineering to undergraduates over the last few years, 
we have used these ‘module dependence diagrams’ to explain software designs, 
and have required students to produce them as documentation [6]. But we have 
come to realize that these diagrams are inadequate, and often do not capture 
the insights that motivate a design: 

— Transitivity. The dependency relation is, by definition, transitive, when in- 
tuitively it should not be. If A uses B and B uses C, then, in the absence of 
additional information, we must assume that any change to C affects B, and 
thus indirectly A, and thus A uses C. But perhaps B was inserted between A 
and C precisely to shield A from changes to C, and most changes to C will not 
affect A. 

— Polymorphism. Crucial elements of modern languages, such as polymorphism 
and interfaces, are not accommodated. Consider a typical Java program in 
which a client class C makes use of a hashtable class H and a key class K. 
Does H depend on K? On the one hand, the code of H makes no reference 
to the code of K; H likely belongs to a library that was written before K. On 
the other hand, changes to K can certainly cause H to fail. If the equals and 
hashCode methods of K are incompatible, for example, a crucial representa- 
tion invariant of the hashtable will be violated (that equal keys are kept in 
the same bucket chains), and a lookup with a given key may not return the 
value last inserted under that key. 

— Preconditions. Presenting a module with a bad procedure argument can 
cause it to fail. If a module’s specification imposes a precondition, the de- 
signer’s intent was that blame for a bad input should be attributed to the 
calling module. But a module cannot easily be said to ‘use’ the modules that 
call it. 

— Replacement. Since a dependence of A on B does not indicate which properties 
of B are actually used by A, one cannot tell what properties of B should be 
preserved in a module that replaces it. The dependence diagram cannot 
therefore be used to reason about compatibility of components. 

3 A New Model 

Our new model is based on two simple ideas. First, a dependence represents an 
assumption: a module A depends on a module B if the designer or implementer 
of A makes an assumption about the environment in which A is to be inserted 
that is justified in the constructed system by the presence of B. The assumption 
may be that A is executed with a certain frequency; or that values passed to it 
satisfy certain conditions; or that values returned to it by procedures it calls are 
related to the values it passed them in certain ways. 

Second, dependences are mediated by specifications: one module does not 
depend directly on another, but rather on a specification which the other module 
must satisfy. A dependence of module A on module B mediated by specification 
S means that A assumes the conditions guaranteed by S, which the system is 
configured to provide through B. 
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These notions address some but not all of the deficiencies of the standard 
model: 

— There is no transitivity problem, because of the interposed specifications. If 
A depends on B via specification S, and B depends on C via specification T, it 
is clear that changes to C that preserve the behaviour required by T will not 
affect B, and of the changes that affect B, only those that cause B no longer 
to satisfy S will affect A. 

— The use of polymorphic modules is clarified. A hashtable H depends on its 
key class K via the specification Object — what in Java is referred to as ‘the 
object contract’. The dependence of H on K is an artifact of the configuration: 
in this case due to some client class C passing objects of type K to the 
hashtable class H. The designer of H is not expected to predict the use of K, 
but can assume that any class whose objects are used as keys will satisfy 
Object. 

— A precondition is represented by a dependence in the reverse direction; the 
pre- and postconditions of a procecure specification can be regarded as dis- 
tinct specifications associated with data flows in different directions. 

— Reasoning about replacement comes easily as a byproduct of the use of spec- 
ifications. A dependence of a module that makes the assumption described 
in specification S will be preserved appropriately if the module it depends 
on is replaced by one that also satisfies S. If specifications are treated as un- 
interpreted names (which will often be convenient), an explicit ordering on 
specifications can be used to justify replacements that do not involve exact 
matches. 

Specifications appear, at least implicitly, in the traditional model, but they 
play a different role. In Parnas’s formulation, the specification of the using mod- 
ule, and not the used module is relevant. Furthermore, in our model, specifica- 
tions are associated with dependences rather than modules. A single module may 
have many specifications, each representing a view of the module presented to 
another module that depends on it. In the hashtable example, key class K appears 
to the hashtable class H under the specification Object, but will likely appear 
to the client class C under a stronger specification that provides domain-specific 
properties. 

4 Example: Observer 

Many of the ‘Gang of Four’ design patterns [3] are motivated by dependence 
considerations. We illustrate our dependence model on the Observer pattern. 

The figure shows dependence diagrams for a fragment of a program that has 
been refactored with Observer. The original program on the left has a subject 
class Subj and a concrete observer class CObs. Updates to Subj from a client 
class Client are propagated to CObs by calls to procedures specific to CObs. We 
have shown this by labelling the dependence with a specification CObs: using 
the name of the module for the specification is intended to suggest that the 
specification promises all the properties the module is designed to provide. 
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The refactored program on the right differs primarily in the specifications 
that mediate the dependences. The key difference is that Subj no longer in- 
teracts with CObs via the specification CObs, but rather through a far weaker 
specification Obs, a generic observer specification that could be used for other 
observer classes. This is the central motivation of Observer: it allows new ob- 
server classes to be added without changing the code of Subj . There is a back 
dependence from CObs to Subj mediated by the specification Get representing 
the calls CObs must now make to Subj to obtain state updates. 

The relationship between the client class Client and the subject Subj has 
been refined to show two different interactions. The dependence mediated by 
the specification Update stands for the service Subj provides in updating its 
internal state in response to requests from Client. The label Reg stands for 
the registration service that Subj provides in which an object is added to its 
internal record of observers. There are two dependences associated with the Reg, 
shown as a double-headed arrow, corresponding to the pre- and postconditions 
of the registration operation. The precondition, shown as an arrow from Subj to 
Client, represents the obligation of Client to avoid registering observers that 
might create observation cycles. 

Finally, there is a new dependence of Client on CObs, since the client class 
is now required to handle the observer object when it registers it. Assuming 
that Client creates the observer object, we can label the dependence with a 
specification ConsObs to represent the use of a constructor, but probably no 
other operations. 

It is typical of a design pattern that the code is in some respects made more 
complicated. There are more dependences after the pattern has been applied, but 
they are more systematically organized. Most importantly, some aspects of the 
behaviour are factored out into dependences mediated by generic specifications 
(Reg and Obs). These specifications are the hallmark of the pattern. 

5 Discussion 

The dependence structure of a program is not trivially extractable from its code. 
For one thing, it may not be easy to determine which module in a system 
discharges the obligations incurred by another module’s assumptions. In the 
hashtable example, finding the dependence of the hashtable module H on the 
key module K would require at least a type-based analysis to determine what 
types of object are inserted into the table. 
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Moreover, dependences represent the designer’s subjective view of how re- 
sponsibilities are partitioned amongst modules. In the Observer example, we 
have taken the traditional abstract data type viewpoint that the subject class, 
and the observer indirectly, provide a service to the client. But an equally tenable 
viewpoint is that the observer class depends on the services of the other classes: 
its specification requires it to display certain state changes, and it therefore 
requires notification of when those changes occur. In this viewpoint, the noti- 
fication dependence from Subj to CObs is reversed. Similarly, in the hashtable 
example, the concern about keys might have been expressed as a precondition 
dependence from the hashtable class H to the client class C that assigns blame 
to C for passing a bad key to H on a call to add. 

Dependence diagrams should not be confused with class diagrams or object 
models. A class diagram is just a graphical representation of the syntactic struc- 
ture of an object-oriented program, showing the inheritance hierarchy and the 
source and target classes of instance variables. An object model is a graphical 
representation of a heap invariant [4]: it is thus semantic where the module 
dependence diagram is syntactic. 

Since a module can be viewed as not only requiring multiple services, but also 
providing multiple services, it may be useful to track the relationship between the 
two. An enriched dependence diagram might include a relation for each module 
between its incoming and outgoing specifications. One could then perform a kind 
of ‘module slice’, following dependences between modules and within modules. 
The set of modules on which a module depends indirectly might be smaller than 
the set that would be obtained simply by following dependence edges between 
modules, especially for object-oriented programs in which the ’roles’ a class plays 
are often largely independent. In the Observer example, such an analysis would 
show that the Reg dependence on Subj is not propagated further; the Update 
dependence, in contrast, is propagated to the Obs and Get dependences. 

Some important forms of coupling are not captured in our model or in the 
standard model, most notably those due to sharing. Suppose module M uses 
module W to write a file and module R to read it; the file may be used to store 
state (such as a browser’s bookmarks) across executions of the program, for 
example. The format with which W writes the file must be the same format with 
which R reads it. A change to W may therefore break R. But neither provides 
a service to the other, so the standard notion of dependence finds no coupling 
between them. 

Our new model seems to offer some new insight into software designs and 
their rationale, but it is far from complete. Plans to develop it further include: 

~ Sorting out the relationship between dependences and code, and develop- 
ing analysis algorithms for extracting at least approximate dependences. In 
Java, it should be possible to use rudimentary type inference to find depen- 
dences (in the style of Womble [5]) and to synthesize specification labels from 
explicit use of interfaces or from the use of subsets of a class’s methods. 
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— Investigating the use of dependences in reasoning about which parts of a 
system compromise critical modules. Precondition dependences seem to offer 
some promise in representing couplings that are missed by the traditional 
model. 

— Finding a way to represent couplings due to sharing, perhaps using the shar- 
ing constraints of the ML programming language [7] or the parameter bind- 
ing constraints of Units [2] . 

— Establishing a better understanding of the role of dependences in software 
engineering, perhaps along the lines of Eppinger’s work [1] in conventional 
engineering on the design structure matrix and its applications. 

Since this paper was written, an analysis of the code of a radiotherapy machine 
was conducted using the dependence model [9] . It exposed a number of serious 
issues. 
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Abstract. UFO is a new application framework in which programs written in 
FORMAN, a declarative assertion language, are compiled into execution moni- 
tors that run on a virtual machine with extensive monitoring capabilities pro- 
vided by the Alamo monitor architecture. FORMAN provides an event trace 
model in which precedence and inclusion relations define a DAG structure that 
abstracts execution behavior. Compiling FORMAN assertions into hybrid run- 
time/post-mortem monitors allows substantial speed and size improvements 
over post-mortem analyzers. The UFO compiler generates code that computes 
the minimal projection of the DAG necessary for a given set of assertions. UFO 
enables fully automatic execution monitoring of real programs. The approach is 
non-intrusive with respect to program source code and provides a high level of 
abstraction for monitoring and debugging activities. The ability to compile 
suites of debugging rules into efficient monitors, and apply them genetically to 
different programs, enables long-overdue breakthroughs in program debugging. 



1 Motivation 

Debugging is one of the most challenging and least developed areas of software engi- 
neering. A special issue of Communications of the ACM characterized the current 
state of debugging tools as a “Debugging scandal” [1]. According to the classic 
“Brook’s rule” [2] more than 50% of all time and effort in a software project is spent 
in testing and debugging activities. Typical activities include detection and removal of 
errors, profiling, and performance tuning. 

Debugging activities include queries regarding many aspects of target program be- 
havior: sequences of steps performed, histories of variable values, function call hier- 
archies, checking of pre- and post-conditions at specific points, and validating other 
assertions about program execution. Performance testing and debugging involves a 
variety of profiles and time measurements. Visualization is another common debug- 
ging activity that may help locate logic or performance problems. 

There is an urgent need for tools that automate the primary, labor-intensive tasks 
of debugging, but progress has been slow. Debugging automation has its own system 
of ideas and domain-specific programming activities. Support for these concepts and 
activities is essential in order to move debugging automation forward. 

We are building automatic debugging tools based on precise program execution 
behavior models that enable us to employ a systematic approach. Our program behav- 
ior models are based on events and event traces [3][4][5]. Debugging automation 
refers to a computation over an event trace. Program execution monitors are programs 
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that load and execute a target program, obtain events at run-time, and perform compu- 
tations over the event trace. Computations are performed during execution, post- 
mortem, or in any mixture of both times. 

Any detectable action performed during a target program’s run time is an event. 
For instance, expression evaluations, statement executions, and procedure calls are all 
examples of events. An event has a beginning, an end, and some duration; it occupies 
a time interval during program execution. This leads to the introduction of two basic 
binary relations on events: partial ordering and inclusion. Those relations are deter- 
mined by target language syntax and semantics, e.g. two statement execution events 
may be ordered, or an expression evaluation event may occur inside a statement exe- 
cution event. The set of events produced at run time, together with ordering and inclu- 
sion relations, is called an event trace and represents a model of program behavior. 
An event trace forms an acyclic directed graph (DAG) with two types of edges corre- 
sponding to the basic relations. 

Our previous work included the FORMAN assertion language [3] and the Alamo 
program execution monitoring architecture [6]. FORMAN takes a top-down ap- 
proach, introducing a domain-specific syntax for expressing bug manifestations and 
other behavior of interest, while Alamo takes a more bottom-up, implementation- 
driven approach, providing runtime system support for the development of monitors 
in which efficiency and scalability to real programs are primary concerns. Alamo’s 
efficient source-level access and control over monitored programs has been integrated 
into a production virtual machine; in the absence of such support, monitoring would 
require extensive low-level instrumentation and control mechanisms. 

The language UFO (Unicon-FORMAN) integrates the experience accumulated in 
these previous projects to provide a complete solution for development of an exten- 
sive suite of automatic debugging tools. UFO is an implementation of FORMAN for 
debugging programs written in the Unicon and Icon programming languages [7] [8]. 
Previous FORMAN implementations worked on subsets of Pascal, and C languages 
and used post-mortem event trace processing methods that limited their applicability. 
In contrast, UFO uses the Alamo monitoring architecture that pervades the Unicon 
virtual machine to support debugging real programs at run time. 



2 Unicon and Alamo 

The Unicon language and the Alamo monitoring architecture provide the underlying 
research framework for the implementation of UFO. Unicon is an imperative, goal- 
directed, object-oriented superset of the Icon programming language. Unicon's syntax 
is similar to Pascal or Java, while its semantics are higher level, featuring built-in 
backtracking and heterogeneous data structures and string scanning facilities. Icon has 
influenced many scripting languages such as Python. Unicon is Icon’s direct descen- 
dant, derived from Icon's implementation. It runs regular Icon programs and extends 
Icon's reach with object-orientation and packages, as well as a much richer system 
interface with high level graphics, networking, and database facilities. 

The reference implementation of Unicon is a virtual machine. Virtual machines 
(VM) are attractive to language implementers, enhancing portability and allowing 
simpler implementation of very high level language features such as backtracking. 
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VMs are also ideal for developing debugging tools. VMs provide an appropriate 
level of abstraction for developing behavior models to describe program executions in 
a processor independent manner, as illustrated by the JPAX tool [9]. VMs also pro- 
vide easy access to program state and control flow, the information most needed for 
debugging activities. Automatic instrumentation on multiple semantic levels is greatly 
simplified via the use of a VM. This potential was exploited in the Unicon VM by a 
framework that implements the Alamo monitoring architecture. Event instrumentation 
and processing support are an integral part of the VM. 

The Alamo Unicon framework is summarized in Figure 1. Execution monitors 
(EM) and the target program (TP) execute as (sets of) coroutines with separate stacks 
and heaps inside a common VM. The VM is instrumented with approximately 150 
kinds of atomic events, each one reporting a <code,value> pair. EMs specify catego- 
ries of events by supplying an event mask when they activate the TP by coroutine 
switch. The TP executes up to an event of interest. 




Fig. 1. Alamo architecture within the Unicon VM. 



The event mask is used by the VM for instrumentation selection and control. Event 
reports during TP execution are coroutine context switches from the VM runtime 
system back to the execution monitor. In addition to the <code,value> reported for the 
event, the EM can directly access arbitrary variable values and state information from 
the TP via state access functions. Monitors are written independently from the target 
program, and can be applied to any target program without recompiling the monitor 
or target program. Monitors dynamically load target programs, and can easily query 
the state of arbitrary variables at each event report. Multiple monitors can monitor a 
program execution, under the direction of a monitor coordinator. 

Alamo’s goal was to reduce the difficulty of writing execution monitors to be just 
as easy as writing other types of application programs. UFO moves beyond Alamo to 
efficiently support FORMAN’s more ambitious goal of reducing the difficulty of 
writing automatic debuggers to the task of specifying generic assertions about pro- 
gram behavior. UFO’s FORMAN language is described in Section 4 below, but first it 
is necessary to present the underlying behavior model. 



3 An Event Grammar for Unicon 

Event grammars provide a model of program run time behavior. Monitors do not have 
to parse events using this grammar, since event detection is part of VM and UFO 
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runtime system functionality. Monitors implement computations over event traces 
supplied by the VM. An event is an abstraction of a detectable action performed at 
run time and has an event type and various attributes associated with it. The following 
description in fact provides a “lightweight” semantics of the Unicon programming 
language tailored for specification of debugging activities. An event corresponds to 
some specific action of interest performed during program execution. Event type is an 
important part of the behavior model. 

Universal attributes are found in every event. They frequently are used to narrow 
assertions down to a particular domain (function, variable, value) of interest. Some of 
these attributes are much easier to obtain than others, and affect the optimizations that 
can be performed when generating monitor code; see Section 5 for details. 
source_text: in a canonical form 

line_num, col_num: source text locations 

time_at_end, time_at_begin, duration: timing attributes 

eval_at_begin (Unicon-expr), 

eval_at_end (Unicon-expr): runtime access to the program states 

prev_path, following_path: set of events before/after this event 

Event types and their type-specific attributes are summarized in the table below. 



Event Type 


Description 


Type Specific Attributes 


prog_ex 


Whole program execution 




expr_eval 


expression evaluation 


value, operator, type, failure_p 


func_call 


function call 


func_name, paramlist 


input, output 


I/O 


file 


variable 


variable reference 




literal 


reference to a constant value 




Ihp 


lefthand part, assignment 


address 


rhp 


righthand part, assignment 




clause 


then-, else-, or case branch execution 




test 


test evaluation 




iteration 


loop iteration 





Event types form a hierarchy, shown in Eigure 2. Subtypes inherit attributes from 
the parent type. Expression evaluation is the central action during Unicon program 
execution, this explains why the expr_eval event is on the top of the hierarchy. 



expr_eval 



clause iteration test Ihp func_call rhp variable param literal 



input output 



Fig 2. Event Type Inheritance Hierarchy 
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The UFO event grammar for Unicon is a set of axioms describing the structure of 
event traces with respect to the two basic relations: inclusion and precedence. The 
grammar is one possible abstraction of Unicon semantics; other event grammars with 
far more (or less) detail might be used. The event grammar limits what kinds of bugs 
can be detected, so some detail is useful. The grammar uses the following notation: 



Notation 


Meaning 


A :: (B C) 


B precedes A, A includes B and C 


A* 


Zero or more A’s under precedence 


A-h 


One or more A’s under precedence 


A|B 


Either A or B ; alternative 


A? 


A is optional 


{ A,B } 


Set; A and B have no precedence 


X : A 


Let X denote event A 



unary op 
binary op 

conditional / case expressions 
loops 



prog_ex:: ( expr_eval *) 

expr_eval:: ( ( expr_eval ) | 

( expr_eval expr_eval ) 
( expr_eval+ ) | 

( test clause ) | 

( iteration * ) | 

( { Ihp, rhp} ) 



) 

iteration:: ( test expr_eval*) | ( expr 



assignment 

Ihp and rhp are not ordered, beginning of 
Ihp precedes rhp, and end of Ihp follows rhp 



eval* test ) | ( expr_eval * ) 



Execution of a Unicon program produces a set of events (an event trace) organized 
by precedence and inclusion into a DAG. The structure of the event trace (event 
types, precedence and inclusion of events) is constrained by the event grammar axi- 
oms above. The event trace models Unicon program behavior and provides a basis to 
define different kinds of debugging activities (assertion checking, debugging queries, 
profiles, debugging rules, behavior visualization) as appropriate computations over 
the event traces. 



4 FORMAN 

Alamo allows efficient monitors to be constructed in Unicon, but using a special- 
purpose language such as FORMAN, with the rich behavior model described in the 
preceding section, has compelling advantages. On a basic level, for example, it is 
convenient to refer to target program variables directly instead of through a library 
call. For example, in FORMAN we may refer to target program variable x, while in 
the Unicon monitor it is referenced as variable("x", &eventsource). UFO rules are 
up to an order of magnitude smaller (in terms of lines of source code) than the equiva- 
lent imperative monitors written in Unicon, depending on the type of quantifiers and 
aggregate operations used in the FORMAN rule. 
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More important than such conveniences are FORMAN’s control structures that di- 
rectly support dynamic analysis. FORMAN supports computations over event traces 
centered around event patterns and aggregate operations over events. The simplest 
event pattern consists of a single event type and matches successfully an event of this 
type or an event of a subtype of this type. Event patterns may include event attributes 
and other event patterns to specify the context of an event under consideration. For 
example, the event pattern 

E: expr_eval & E. operator == ii; = n 

matches an event of assignment. Temporary variable E provides an access to the 
events under consideration within the pattern. 

The following example demonstrates the use of an aggregate operation. 

CARD [A: func_call & A.func_name == "read" FROM prog_ex] 

yields a number of events satisfying the given event pattern, collected from the whole 
execution history. Expression [...] is a list constructor and CARD is an abbreviation 
for a reduction of 'h-' operation over the more general list constructor: 

-I-/ [A: func_call & A. func_name=="read" FROM prog_ex APPLY 1] 

Quantifiers are introduced as abbreviations for reductions of Boolean operations 
OR and AND. For instance, 

FOREACH Pattern FROM event_set Boolean_expr 
is an abbreviation for 

AND/ [Pattern FROM event_set APPLY Boolean_expr ] 

Debugging rules in FORMAN usually have the form: 

Quantifi ed_expressi on 

WHEN SUCCEEDS SAY-clauses 
WHEN EAILS SAY-clauses 

The Quantified_expression is optional and defaults to TRUE. The execution of 
FORMAN programs relies on the Unicon monitors embedded in a VM environment. 
Section 5 below describes the architecture of the UFO compiler and runtime system, 
which translates FORMAN to Unicon VM monitor code. 

The following examples illustrate additional features of FORMAN as needed. 

Application-Specific Analyses 

This section presents formalizations of typical debugging rules. UFO supports and 
improves upon the most common application-specific debugging techniques. For 
example, UFO supports traditional precondition checking, or print statement inser- 
tion, without any modification of the target program source code. This is especially 
valuable when the precondition check or print statement is needed in not just one 
location, but instead in many locations scattered throughout the code. 

Example #1: Tracing. Probably the most common debugging method is to insert 
output statements to generate trace files, log files, and so forth. This allows for subse- 
quent human analysis, and while it has its limitations, it will remain a common tech- 
nique. It is possible to request evaluation of arbitrary Unicon expressions at the be- 
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ginning or at the end of events. The VM evaluates these expressions at the indicated 
time moments, allowing dynamic instrumentation of the Unicon program, whether to 
print some values, or to call a visualization library subroutine. 

FOREACH A: func_call & A.func_name == "my_func" FROM prog_ex 
A. value_at_begin (write ( "entering my_func, value of X is:",X)) 
AND 

A. value_at_end (write ( "leaving my_func, value of X is:", X)) 

This debugging rule causes calls to write ( ) to be evaluated at selected points at 
run time, just before and after each occurrence of event A. 

Example #2; Profiling. A myriad of tools are based on a premise of accumulating the 
number of times a behavior occurs, or the amount of time spent in a particular activity 
or section of code. The following debugging rule illustrates such computations over 
the event trace. 

SAY( "Total number of read() statements: ” 

CARD[ r: input & r. filename == "xx.in" FROM prog_ex ] 
"Elapsed time for read operations is: " 

SUM [ r: input & r. filename == "xx.in" FROM prog_ex 
APPLY r. duration] ) 

Example #3; Pre- and Post-conditions. Typical use of assertions includes checking 
pre- and post-conditions of function calls. 

FOREACH A:func_call & A . f unc_name== " sqrt " FROM prog_ex 
A.paramlist [1] >=0 AND 

abs (A. value*A. value-A.paramlist [1] ) < epsilon 
WHEN FAILS SAY ( "bad sqrt ( " A.paramlist [1] ") yields " A. value) 

Generic Bug Descriptions 

Another interesting prospect is the development of a suite of generic automated de- 
bugging tools that can be used on any Unicon program. UFO provides a level of ab- 
straction sufficient for specifying typical bugs and debugging rules. 

Example #4: Detecting Use of Un-initialized Variables. Although reading an un- 
initialized variable is permissible in Unicon, this practice often leads to errors. There- 
fore, in this debugging rule all variables within the target program are checked to 
ensure that they are initialized before they are used. 

FOREACH V: variable FROM prog_ex 

FIND D: Ihp FROM V.prev__path D . source_text == V. source_text 

WHEN FAILS SAY ( " uninitialized variable " V. source_text) 

Example #5: Empty Pops. Removing an element from an empty list is representative 
of many expressions that fail silently in Unicon. While this can be convenient, it can 
also be a source of difficult to detect logic errors. This assertion assures that items are 
not removed from empty lists. 

FOREACH a:func_call & a. func_name=="pop" & 

a.value_at_begin(*a.paramlist [1] ==0) 

SAY( "Popping from empty list at event " a) 
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5 Implementation Issues 

The most important of implementation issues is the translation model by which 
FORMAN rules are compiled into Unicon monitors. Rules are written as if they have 
the complete post-mortem event trace available for processing. This generality is 
powerful; however the majority of assertions can be compiled into monitors that exe- 
cute entirely at runtime. Runtime monitoring is the key to practical implementation. 
For assertions that require post-mortem analysis, the UFO runtime system computes a 
projection of the execution DAG needed to perform the analysis. 

The UFO translation model categorizes each rule as either “runtime”, “post- 
mortem”, or “hybrid”, denoting the amount of computations that can be performed at 
runtime. Runtime and hybrid categories are determined by constraints on FORMAN 
quantifier prefixes and result in more efficient code. Nested quantifiers and aggregate 
operations generally require post-mortem operation. 

Translation Examples 

Each FORMAN statement is translated into a combination of initialization, run-time, 
and post-mortem code. Monitors are executed as coroutines with the Unicon target 
program, as explained in Section 2. The following examples give a flavor of the run 
time architecture of monitors generated from the UFO high level rules. 

Implementation of Example #1. A lone FOREACH quantifier is typical of many 
UEO debugging actions and allows computation to be performed entirely at runtime. 
The events being counted and values being accumulated determine an event mask in 
the initialization code that defines the Alamo events that will be monitored. The 
monitor’ s event processing loop implements a filter based on procedure name within 
an if-expression. The Unicon code blocks containing write() expressions are inserted 
directly into the event loop for the relevant events. The complete monitor is: 

$ include "evdefs.icn" 
link evinit 
procedure main(av) 

Evlnit(av) | stop("can't monitor ", av[l]) 
mask := E_Pcall ++ E_Pret ++ E_Pfail ++ E_Prem 
while EvGet (mask) do { 

if &eventcode == E_Pcall & &eventvalue === my_func then 

write ( "entering my_func, value of X is:", X) # BEEORE 

if &eventcode == (E_Pret | E_Pfail | E_Prem) & 

&eventvalue=== my_func then 

write ( "leaving my_func, value of X is:", X) # AFTER 

} 

end 

Implementation of Example #2. Another typical situation involves an aggregate 
operation and selection of events according to a given pattern. The SAY expression is 
implemented by a call to write(); it must be performed post-mortem since it uses 
parameters whose values are constructed during the entire program execution. CARD 
denotes a counter, while SUM denotes an accumulator H-/; both require a variable that 
is initialized to zero. The event subtypes and constraints are used to generate addi- 




212 Clinton Jeffery, Mikhail Auguston, and Scott Underwood 



tional conditional code in the body of the event processing loop. Lastly, some attrib- 
utes such as r. duration require additional events and measurements besides the initial 
triggering event. In the case of r. duration, a time measurement between the function 
call and its return is needed. 

$ include "evdefs.icn" 
link evinit 
procedure main(av) 

Evlnit(av) | stop(”can't monitor ", av[l]) 
cardreads := sumreadtime := 0 
mask := cset (E_Fcall ) 
while EvGet (mask) do { 

### count CARD of r:input... 

if &eventcode == E_Fcall & &eventvalue === (read | reads) then 
cardreads +:= 1 

### add SUM of r. duration for r: input 

if &eventcode == E_Fcall & &eventvalue=== (read | reads ) then { 
thiscall := Sctime 
EvGet (E_Ffail++E_Fret) 
sumreadtime +:= &time - thiscall 
} 

} 

### Translation of SAY 

write ("Total number of read() statements: ", cardreads, "\n", 
"Elapsed time for read operations is: ", sumreadtime) 

end 

Basic Generation Templates 

The preceding handwritten example monitors use a single main loop that implements 
traditional event-driven processing. Monitors generated by the UFO compiler reduce 
complex assertions to this same single event loop. Keeping event detection in a single 
loop allows uniform processing of multiple event types used by multiple monitors. 
The code generated by the UFO compiler integrates event detection, attribute collec- 
tion, and aggregate operation accumulation in the main event loop. 

Assertions in UFO that use nested quantifiers entail two nested loops. Code gen- 
eration flattens this loop structure, and postpones assertion processing until required 
information is available. A hybrid code generation strategy performs runtime process- 
ing whenever possible, delaying analyses until post-mortem time when necessary. 
Different assertions require different degrees of trace projection storage; code respon- 
sible for trace projection collection is also arranged within the main loop. 

Each UFO rule falls in one of the following categories which determines its code 
generation template in the current implementation. We have not found a use for asser- 
tions requiring more than two nested quantifiers. 

Compiler-Based Optimizations 

The advantage of the UFO approach is the combination of an optimizing compiler for 
monitoring code with efficient run-time event detection and reporting. Since we know 
at compile time all necessary event types and attributes required for a given UFO 
program, the generated monitor is very selective about the behavior that it observes. 
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Type 


FORMAN template 


Pseudocode 


I 


Single quantifier. Rule applies to 
whole trace(prog_ex); evaluates at 
runtime. 


See examples in Section 4. 1 . 


II 


Nested quantifiers of the form 
Quantifier A: Pattern_A 

Quantifier B: Pattern_B FRQM A 
Body 

This requires accumulation of a trace 
projection for B-events and causes a 
mild overhead at runtime. 


Main Loop 

Maintain stack of nested A 
events 

Accumulate events B in a B-list 
If end of event A 
Loop over B-list 
Do Body 

Endif 

If stack of A is empty 
Destroy B-list 
End of Main Loop 


III 


Nested quantifiers of the form 

Quantifier A: Pattern_A 
Quantifier B: Pattern_B 

FRQM A .prev_path 

Body 

Accumulates a trace projection for B- 
events and may cause a heavy over- 
head at runtime. The B-list can not 
be deleted till the end of session. 


Main Loop 

Maintain stack of nested A 
events 

Accumulate events B In a B-llst 
If end of event A 
Loop over B-list 
If B precedes A 
Do Body 
Endif 

End of Main Loop 


IV 


Nested quantifiers of the form 

Quantifier A: Pattern_A 
Quantifier B: Pattern_B 

FRQM A .following_path 
(or FRQM prog_ex) 

Body 

Accumulates trace projections for 
both A and B events and causes a 
very heavy overhead at runtime. 


Main Loop 

Accumulate events A in A-list 
Accumulate events B in B-list 
End of Main Loop 
# Postmortem Loop 
Loop over A-list 
Loop over B-list 
Do Body 

End of Postmortem Loop 



For certain UFO constructs, such as nested quantifiers, monitors accumulate a siz- 
able projection of the complete event trace and postpone corresponding computations 
until required information is available. The use of the previous_path and follow- 
ing_path attributes in UFO assertions facilitates this kind of optimization. 

For further optimization, especially in the case of programs containing a signifi- 
cant number of modules, the following FORMAN construct limits event processing to 
events generated within the bodies of functions FI, F2, . . . , Fn. 

WITHIN FI , F2 , ... , Fn DO 
Rules 

END_WITHIN 

This provides for monitoring only selected segments of the event trace. 





214 Clinton Jeffery, Mikhail Auguston, and Scott Underwood 



Unicon expressions included in the value_at_begin and value_at_end attributes are 
evaluated at run time. Some other optimizations implemented in this version are: 

• only attributes used in the UFO rule are collected in the generated monitor; 

• an efficient mechanism for event trace projection management, which disposes 
from the stored trace projection those events that will not be used after a certain 
time (for example, see Category II); 

• event types and context conditions are used to filter events for the processing. 
UFO’s goal of practical application to real-sized programs has motivated several 

improvements to the already-carefully-tuned Alamo instrumentation of the Unicon 
VM. We are working on additional optimizations. 



6 Results of Sample Assertion Execution 

Table 1 gives results from executing rules written in UFO on a sample target program, 
a 1,100 line version of egrep. Tests were run on a 700 MHz Solaris machine with 
512MB of RAM. The results reported are number of events generated by the VM and 
execution time averaged over several runs. Execution time is reported as min- 
utes:seconds.tenths. The second row contains the time for program execution without 
monitoring. Each program/input file combination was monitored by 8 different asser- 
tions corresponding to the basic generation templates. 

Cases 1-4 are examples of a Category I template. Case 5 is a Category II rule. 
Case 6 is a Category III rule. It uses PREV_PATH and accumulates a trace projection 
over part of the program execution. Cases 7 and 8 contain nested quantifiers that be- 
long to Category IV. These assertions require the accumulation of two trace projec- 
tions over the entire program execution, and complete post-mortem processing. Case 
9 is composed of all the previous assertions to yield a monitor that combines multiple 
assertions on a single execution of the target program. 



Table 1. Results for igrep.icn. 



Input Size (lines) 


4000 


16000 


64000 


No monitoring 


0.5 


1.6 


6.4 




Events 


Time 


Events 


Time 


Events 


Time 


Casel 


184208 


4.1 


736208 


16.2 


2944208 


1 : 04.9 


Case 2 


284123 


4.6 


1136123 


18.1 


4544123 


1 : 12.9 


Case 3 


184208 


3.4 


736208 


13.5 


2944208 


54.0 


Case 4 


184208 


3.5 


736208 


13.6 


2944208 


54.0 


Case 5 


276306 


6.3 


1104306 


28.0 


4416306 


2 : 09.3 


Case 6 


276306 


6.5 


1104306 


28.4 


4416306 


2 : 11.8 


Case? 


276306 


6.5 


1104306 


29.1 


4416306 


2 : 11.3 


Case 8 


276306 


6.5 


1104306 


29.4 


4416306 


2 : 12.6 


Case 9 


340306 


45.9 


1360306 


3 : 57.8 


5440306 


20 : 38.6 
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The results depicted in this table allow several observations. Average monitoring 
speeds on simple assertions in the test environment were in the range of 2-3 million 
events per minute. Monitoring realistic assertions on real-size programs with real-size 
input data is feasible with this system. Most assertions impose about one order of 
magnitude execution slowdown compared with the unmonitored program execution. 

The execution time required by the combination of all assertions (Case 9) is longer 
than the sums of separate monitor executions. Combined assertion executions have 
greater memory requirements in the current implementation, because separately col- 
lected trace projections compete for available cache and virtual memory resources. 
Multi-assertion optimizations are not yet implemented in the current UFO compiler. 



7 Related Work 

What follows is a very brief survey of basic ideas known in Debugging Automation to 
provide the background for the approach advocated in this paper. 

The Event Based Behavioral Abstraction (EBBA) [10] characterizes the behavior 
of programs in terms of primitive and composite events. Context conditions involving 
event attributes are used to distinguish events. EBBA defines two higher-level means 
for modeling system behavior — clustering and filtering. Clustering is used to express 
behavior as composite events, i.e. aggregates of previously defined events. Eiltering 
serves to eliminate from consideration events, which are not relevant to the model 
being investigated. Both event recognition and filtering can be performed at run-time. 

Event-based debuggers for the C programming language built on top of GDB in- 
clude Dalek [11] and COCA [12]. Dalek supports user-defined events that typically 
are points within a program execution trace. A target program has to be manually 
instrumented in order to collect values of event attributes. Composite events can be 
recognized at run-time as collections of primitive events. COCA uses GDB for tracing 
and PROLOG for the execution of debugging queries. It provides an event grammar 
for C and event patterns based on attributes for event search. The query language is 
designed around special primitives built into the PROLOG query evaluator. 

Assertion languages provide another approach to debugging automation. Boolean 
expressions are attached to points in the target program, like the assert]) macro in C. 
[13] advocates a practical approach to programming with assertions for the C lan- 
guage, and demonstrates that even local assertions associated with particular points 
within the program may be extremely useful for program debugging. 

The ANNA [14] annotation language for the Ada language supports assertions on 
variable and type declarations. The TSL [15], [16] annotation language for Ada uses 
events to describe the behavior of Tasks. Patterns can be written which involve pa- 
rameter values of Task entry calls. Assertions are written in Ada using a number of 
special pre-defined predicates. Assertion-checking is performed at run-time. RAPIDE 

[17] provides an event-based assertion language for software architecture description. 
Temporal Rover is a commercial tool for dynamic analysis based on temporal logics 

[18] . The DUEL [19] debugging language introduces expressions for C aggregate 
data exploration, for both assertions and queries. 

Algorithmic debugging was introduced in [20] for the Prolog language. In [21] and 
[22] this paradigm is applied to a subset of PASCAL. The debugger executes the 
program and builds a trace execution tree at the procedure level while saving some 




216 Clinton Jeffery, Mikhail Auguston, and Scott Underwood 



useful trace information such as procedure names and input/output parameter values. 
The debugger traverses the execution tree, asking the user about the intended behavior 
of each procedure. The search finally ends and a bug is localized within a procedure p 
when one of the following holds: procedure p contains no procedure calls, or all pro- 
cedure calls performed from the body of procedure p fulfill the user’s expectations. 
The notion of computation over execution trace introduced in FORMAN is a gener- 
alization of Algorithmic Debugging and is a convenient basis for describing such 
generic debugging strategies. 

PMMS [23] is a high level program monitoring and measuring system. This system 
works by receiving queries from the user about target programs written in the APS 
high level programming language. PMMS instruments the source code of the target 
program in order to gather data necessary to answer the posed questions. This data is 
collected during run time by the monitoring facilities of PMMS and stored in a data- 
base for subsequent analysis. Their domain specific query language is similar to 
FORMAN but tailored for database-style query processing. 

JPAX [9], the Java Path Explorer, provides a means to check execution events 
within a program based on a user provided specification written in Maude, a high 
level logic language. Like UFO, JPAX supports monitoring based on a VM (JVM). 
JPAX supports both black box (based on automatic byte-code instrumentation) and 
white box (based on hand instrumentation) runtime verification. 

Dynascope [24] is a system for directing programs written in vanilla C. A director 
monitors and controls the actions of the program, while an interpreter controls the 
flow of event streams to and from the director in addition to interpreting the program. 
Dynascope can test and debug programs without altering their source code. 

YODA [25] uses a preprocessor to attach statements to a target Ada program. 
These statements activate a monitor creates a trace database and a symbol table to aid 
in debugging. The trace database will contain the program’s history regarding variable 
declaration and use, task synchronization, and change in task status. Prolog queries 
can be issued by the user in order to confirm or reject hypotheses about program be- 
havior. YODA represents a classical post-mortem trace processing paradigm. 



8 Conclusions and Future Work 

The rising popularity of virtual machine architectures enables dramatic improvements 
in automatic debugging. These improvements will only occur if debugging is one of 
the objectives of the VM design, e.g. as in the case of .net [26]. 

The architecture employed in UFO could be adapted for a broad class of languages 
such as those supported by the Java VM or the .net VM. Our approach to debugging 
automation uniformly represents many types of debugging-related activities as com- 
putations over traces, including assertion checking, profiling and performance meas- 
urements, and the detection of typical errors. We have integrated event trace computa- 
tions into a monitoring architecture based on a VM. Preliminary experiments demon- 
strate that this architecture is scalable to real-world programs. 

One of our next steps is to build a repository of formalized knowledge about typi- 
cal bugs in the form of UFO rules, and gather experience by applying this collection 
of assertions to additional real-world applications. There remain many optimizations 
that will improve the monitor code generated by the UFO compiler, for example. 
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merging common code used by multiple assertions in a single monitor, and generating 
specialized VMs adjusted to the generated monitor. 
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Appendix. Syntax for UFO Rules 

Rules::= ( ( Rule | Within_group ) + 

Within_group::= ’WITHIN’ Procedure_name ( ’,’ Procedure_name ) * 

’DO’ ( Rule ’;’ ) -i- ’END_WITHIN’ 

Rule::= [ Label ’:’] 

[ (’FOREACH’ I ’FIND’) Pattern [ ’FROM’ ’PR0G_EX’ ] ] 

[ (’FOREACH’ I ’FIND’) Pattern [ ’FROM’ (’PR0G_EX’ | 

Metavariable [ ’.’ ( ’PREV_PATH’ | ’FOLLOWING_PATH’ )] ) ] 

[ ’SUCH’ ’THAT’ ] BooLexpr 

[[’WHEN’ ’SUCCEEDS’] Say_clause -i- ] [’WHEN’ ’FAILS’ Say_clause -i- ] 
Say_clause ::= ‘SAY’ '(' ( Expression | Metavariable | Aggregate_op ) * ’)' 
Bool_expr::= Bool_expr1 ( 'OR' Bool_expr1 )* 

Bool_expr1::= Bool_expr2 ( 'AND' Bool_expr2 )* 

Bool_expr2::= Expr [('='[ '==' | '>' | '<' | '>=' | '<=' | '[=' ) Expr ] | 'NOT' Bool_expr2 | 
'(' Bool_expr ')' 

Pattern: := Metavariable ':' EvenMype [ '&' BooLexpr ] 

Aggregate_op::= [ ( 'CARD' | 'SUM' ) ] '[' Pattern 

['FROM' ('PROG_EX' | Metavariable [ '.' ( 'PREV_PATH|FOLLOWING_PATH' )] )] 

[ 'APPLY' ( BooLexpr | Expression ) ] ']' 

Expression: := Expr1 (* ( '-i-' | '-') Expr1 *) 

Expri ::= Simple_expr ( ( '*' | 'DIV | 'MOD' ) Simple_expr )* 

Simple_expr::= '-' Simple_expr | integer | Aggregate_op | 

Metavariable '.' Attribute | string | '(' Expr ')' 

Attribute::= (SOURCE_TEXT | LINE_NUM | COL_NUM | TIME_AT_END | 

TIME_AT_BEGIN | COUNTER_AT_END | COUNTER_AT_BEGIN | 
DURATION I VALUE | OPERATOR | TYPE | FAILURE | FUNC_NAME | 

( PARAM_NAMES '[' integer ']' ) | FILE_NAME | ADDRESS | 

( VALUE_AT_BEGIN | VALUE_AT_END) '(' Unicon_expr ')' ) 

Event_type::= (func_call | expr_eval | input | output | variable | literal | 

Ihp I rhp I clause | iteration | test ) 
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Abstract. In software engineering, even with recent active research on 
formal methods and automated tools, users’ involvement is inevitable 
and crucial throughout the software development lifecycle. Automation 
of these manual tasks would assist the developers throughout the devel- 
opment. Our project goal is to help the engineers to resolve ambiguity in 
natural language (NL) using Natural Language Processing and to over- 
come different levels of abstraction between requirements documents and 
formal specifications using Two- Level Grammar (TLG). The result is a 
system that assists developers to build a formal representation from the 
informal requirements for rapid prototyping and complete system imple- 
mentation. 

Keywords: Natural Language Processing, Formal Specification, Auto- 
mated Software Engineering, Two- Level Grammar (TLG). 



1 Introduction 

Even the rigorous development of formal specifications and automated tool kits 
in recent years hasn’t eliminated the practical importance of requirements doc- 
uments written in natural language and the necessity of users’ involvement 
throughout the software development life cycle. 

Even though natural language is inherently object-oriented and descriptive 
with strong representation power, its syntax and semantics are not formal enough 
to be used directly as a programming language. Therefore the requirements doc- 
umentation written in NL has to be reinterpreted into a formal specification 
language by software engineers. Pohl rightly stated regarding this process that 
improving an opaque system comprehension into a complete system specification 
and transforming informal knowledge into formal representations are the major 
tasks in the requirements engineering [1]. When the system is very complicated, 
which is mostly the case when one chooses to use formal specification, this con- 
version, if manually done, is both non-trivial and error-prone, if not implausible. 

Many similar tasks of manual involvement occur and are repeated to translate 
the requirements documents into a formal specification or into final executable 
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code regardless if the type of the system under development. Some examples of 
these tasks are domain-specific knowledge collection, correct interpretation of 
requirements, specification update, and maintenance of consistency, to name a 
few. 

It is well known that as much as 60 percent of the errors that appear during 
a system’s life cycle have their origin in the requirements phase [2]. It is also 
well known that the cost to correct an error found in the implementation and 
later stages of system development is orders of magnitude higher than to correct 
the same error found during the requirements stage [3]. Therefore ensuring the 
correctness of the requirements as well as their interpretation and translation 
cannot be overemphasized. 

The challenge of formalizing a natural language requirements document, 
which takes up major portion of human involvement in the system develop- 
ment, results from many factors such as miscommunication between domain 
experts and engineers. However the major bottleneck of this conversion is from 
the inborn characteristic of ambiguity of NL and the different levels of formalism 
between the two domains of NL and formal specification. 

To handle this ambiguity problem, some have argued that the requirements 
document has to be written in a particular way to reduce ambiguity in the 
document [4]. Others have proposed controlled natural languages (e.g., Attempto 
Controlled English (ACE) [5]) which limit the syntax and semantics of NL to 
avoid the ambiguity problem. Another approach to NL requirements analysis is 
to search each line of the requirements document for specific words and phrases 
for the purpose of quality analysis [6]. A similar project [7] focuses mainly on 
the automatic indexing and reuse of the software components in the requirement 
documents. However there has been no attempt to automate the conversion from 
requirements documentation into a formal specification language for prototyping 
as well as implementation. 

In our research. Natural Language Processing (NLP) [8] is used to handle 
the ambiguity problem in NL and Two Level Grammar (TLG) [9] is used to deal 
with the different formalism level between NL and formal specification languages 
to achieve the automated conversion from NL requirements documentation into 
a formal specification (in our case VDM-I— I- - an object-oriented extension of 
the Vienna Development Method [10]) and to reduce and reuse the developers 
involvement. 

2 Approach 

To achieve the conversion from requirements documents to a formal specification 
several levels of conversions are required. First the original requirements written 
in natural language is refined as a preprocessing of the actual conversion. This 
refinement task involves checking spellings, grammatical errors, consistent use 
of vocabularies, organizing the sentences into the appropriate sections, etc. This 
process is carried out manually by the requirements engineer (s) and it should be 
noted that a well-written requirements document will need little if any prepro- 
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cessing. Next the refined requirements document is automatically translated into 
XML format. By using XML to specify the requirements, XML attributes (meta- 
data) can be added to the requirements to interpret the role of each group of 
the sentences during future conversions. The information of the domain-specific 
knowledge is specified in XML. The domain-specific knowledge describes the 
relationship between components and other constraints that are presumed in re- 
quirements documents or too implicit to be extracted directly from the original 
documents, and it is constructed by the domain engineer(s). 

Then a knowledge base is automatically constructed from the requirements 
document in XML using NLP to parse the documentation and to store the syn- 
tax, semantics, and pragmatics information. In this phase, the ambiguity is de- 
tected and resolved, if possible. If there is difficulty resolving the ambiguity, the 
system may seek assistance from the software engineer(s). Once the knowledge 
base is constructed, its content can be queried in NL. Next the knowledge base is 
automatically converted, with the information of the domain specific knowledge, 
into Two Level Grammar (TLG) by removing the contextual dependency in the 
knowledge base. TLG, the most NL-like specification language which is a unifi- 
cation of functional, logic, and object-oriented programming styles, is used as an 
intermediate representation to build a bridge between the informal knowledge 
base and the formal VDM-I— I- representation. 

Finally the TLG code is translated into VDM-I— I- by data and function map- 
pings. VDM-I— I- is chosen as the target specification language because VDM-I— |- 
has many similarities in structure to TLG and also has a good collection of tools 
for analysis and code generation. Once the VDM-I— I- representation of the speci- 
fication is acquired we can do prototyping of the specification using the VDM-I— |- 
interpreter. Also we can convert this into a high level language such as Java^^ 
or G-l— I- or into a model in the Unified Modeling Language (UML) [11] using 
the VDM-I--I- Toolkit [12]. The entire system structure is shown in Figure 1. 

The translation of our system is incremental and iterative reflecting the 
changes made throughout the system development. The user interaction is likely 
to happen any stage of the translation to supervise and assist the automation. By 
keeping track of user’s preferences and configurations for each iteration and au- 
tomating the translations accordingly, the user’s involvement can be reasonably 
reduced. 

In the sections which follow, we will present the following simplified (thus in- 
complete) Gomputer Assisted Resuscitation Algorithm (GARA) [13] to illustrate 
our approach and describe the various system components. GARA is a closed 
loop infusion pump control software system that drives a high output infusion 
pump used for fluid resuscitation of patients suffering from conditions that lead 
to hypotension. 

HOST is powered up and all software subsystems are available. 

The pump software system is now in the wait operating state. Patient 
with IV/pump running is placed onto the HOST. Pump cable is connected 
to the HOST. HOST now provides power for pump. Pump software system 
detects pump connection and monitors occlusion and airlock logic levels. 
Pump subsystem display is automatically brought forward to the secondary 
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Fig. 1. System Structure. 



display. Pump software subsystem detects back EMF and fluid impedance 
and begins to log infusion rate. Pump continues to operate on it’s 
hardware setting. Pump software system is now in manual operating state. 
One of the blood pressure sensors is connected to the patient. 

Pump software system detects clean blood pressure signal and activates 
automatic servo-control start button. When the start button is pressed 
the MAC controls the pump and begins resuscitation to the prescribed 
blood pressure setpoint. The system is now in the automatic 
servo-control on operating state when the pump is infusing fluid into 
a patient using the hardware (HW) flow setting on the pump. If for any 
reason (change IV bags, change or fix blood pressure sensor, etc.) it 
becomes necessary to pause the MAC, the pause button on the display may 
be pressed. This causes the infusion pumping to cease. The system is 
now in the automatic servo-control paused operating state. The system 
maybe restarted at any time. When the patient is to be removed from 
the HOST, the pump software system should be returned to the manual 
operating state. The blood pressure sensor should be removed from the 
patient and then the pump cable can be removed from the HOST. 

This allows the pump to continue operating in standalone mode or the 
IV infusion to be discontinued. 



3 Requirements in XML 

Rearranging related information together in the requirements will ease the con- 
version. Specially because we are assuming that the requirements can contain 
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different aspects of information (functional, non-functional or even a mixture of 
both) about the system. Even functional requirements can have different types 
of functionality. For example, they can be object-oriented, procedural, real time- 
based, event-based, etc. Rearranging related information together will ease the 
conversion. This can be achieved by specifying the role of each paragraph us- 
ing XML data structure and notations. This will help the knowledge base to 
maintain the correct structure. 

The CARA specification in XML is shown as follows. 

<document> 

<c title = "Mode" meta = "mode"> 

<c title = "wait state" meta = "submode"> 

<p meta = "pre_cond"> 

<s>HDST is powered up and all software subsystems are available</s> 
</p> 

<p meta = "pre_exec"> 

<s>Patient with IV/pump running is placed onto the H0ST</s> 

<s>Pump cable is connected to the H0ST</s> 

</p> 

<p meta = "exec"> 

<s>HQST now provides power for pump</s> 

</p> 

<p meta = "break_cond"> 

<s>When the pump is infusing fluid into a patient using 

the hardware (HW) flow setting on the pump the system is no 
longer in the wait state</s> 

</p> 

</c> 

<c title = "manual state" meta = "submode"> 

<p meta = "pre_exec"> 

<s>Pump software system detects pump connection and monitors occlusion 
and airlock logic levels </s> 

<s>Pump subsystem display is automatically brought forward to the 
secondary display</s> 

<s>Pump software subsystem detects back EMF and fluid impedance and 
begins to log infusion rate</s> 

<s>Pump continues to operate on it’s hardware setting</s> 

<s>0ne of the blood pressure sensors is connected to the patient</s> 
<s>Pump software system detects clean blood pressure signal and 
activates automatic servo-control start button</s> 

</p> 

</c> 

<c title = "autocontrol on state" meta = "submode"> 

<p meta = "pre_exec"> 

<s>When the start button is pressed the MAC controls the pump and 
begins resuscitation to the prescribed blood pressure 
setpoint</ s> 



</p> 

</c> 
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<c title = "autocontrol paused state" meta = "submode"> 

<p meta = "pre_exec"> 

<s>If for any reason (change IV bags, change or fix blood pressure 
sensor, etc.) it becomes necessary to pause the MAC, the 
pause button on the display may be pressed</s> 

<s>This causes the infusion pumping to cease</s> 

</p> 

<p meta = "break_cond"> 

<s>The system maybe restarted at any time</s> 

</p> 

<p meta = "break_exec"> 

<s>When the patient is to be removed from the HOST, the pump software 
system should be returned to the manual operating state</s> 

<s>The blood pressure sensor should be removed from the patient enid 
then the pump cable can be removed from the H0ST</s> 

<s>This allows the pump to continue operating in standalone mode or 
the IV infusion to be discontinued</s> 

</p> 

</c> 

</c> 

</document> 

The meta attribute in XML indicates the role of each paragraph. Namely 
it shows if the group of the sentences describes state types (mode), execution 
types (_exec), various conditions (_cond), etc. submode indicates the state. In 
the CARA example, there are four distinctive states; wait state, manual state, 
autocontrol on state, and autocontrol paused state. In a state, preconditions 
(pre_cond) have to be satisfied to enter the state. Some statements (pre_exec) 
will be executed when the system enters into a state. Other statements (exec) 
will be executed while the system is in the state. If any break conditions (break, 
cond) are satisfied in the state, the system will leave the state. There may be 
some cases where break conditions will execute some statements (break.exec) 
before breaking out of the state. Also some default statements (post.exec) are 
executed before leaving the state. We have specified these meta attributes for 
various types of functionality in requirements to cover a wide range of different 
requirements documents. Using a tree-like structure in XML the specifications 
become more descriptive as the tree expends further. Organizing and represent- 
ing the requirements document in XML according to the roles of the specifica- 
tions of the system not only enhances understanding of specifications but also 
helps to standardize requirements composition. 

4 Domain-Specific Knowledge in XML 

A requirements document usually contains specific information about how the 
system should work whereas the domain knowledge describes how the system is 
composed by its components and the constraints imposed on the components or 
on the relations among them. The domain-specific knowledge is a world knowl- 
edge specific to a certain domain in which the system is defined. This is well 
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tied into the concept of the family or the ontology of systems. Depending on 
the level of abstraction (or the details described) of the domain knowledge, the 
effort to construct it can vary. By limiting the level of abstraction, the body of 
the knowledge can be reduced into a reasonable size and so can the effort to 
build it. Usually the domain-specific knowledge is defined informally or only for 
a specific project, not reusable or extensible for similar systems (the systems 
in the same family). By using XML to specify the domain knowledge with a 
minimum semantics, not only can the specification be formally defined but also 
it can be extensible, gradually building up an ontology of systems. 

In our research the domain knowledge specified in XML shares many similar- 
ities with DARPA Agent Markup Language (DAML) [14] which is a frame-based 
language with semantics to describe ontology. Because domain knowledge is more 
than just an ontology, DAML is not expressive enough to describe the whole as- 
pect of the domain knowledge [15]. However using the XML syntax a domain 
knowledge can be specified in various ways leaving the interpretation of its se- 
mantics totally up to the system that uses it [16]. Therefore when a specification 
for domain-specific knowledge in XML is to be developed, its formal semantics 
as well as its expressiveness has to be considered at the same time. 

The following describes an example of the domain knowledge of Car to illus- 
trate the use of domain-specific knowledge expressed in XML in our project. 



<system name = "Car"> 

<component name = "Engine "> 

<amount type ="exactly" value = "l"/> 

<unit type = "volume" value = "liter"/> 

<subcomponent name="Cylinder" type = "integer"> 

<amount type ="one_of" value = "4,6,8"/> 

</ subcomponent> 

<relation with = "Starter" type ="pass_to" value ="signal"/> 

</ component> 

<component name = "Wheel"/> 

<component name = "Body"> 

<relation with = "Frame" type ="synonym"/> 

</ component> 

<relation with = "Vehicle" type ="inheritance" value ="parent"/> 
<relation with = "Van" type ="inheritance" value ="child"/> 

</ system> 



According to the above domain specification, Car is composed of Engine, 
Wheel, Control, and Body. Vehicle is a parent of car whereas Van is a type 
of Car. Car can have exactly one Engine and the unit of engine is a volume 
expressed in liters. Engine has Cylinder as its subcomponent. The number of 
Cylinders, which is an integer and is a representative part of the subcomponent, 
can be either 2, 6, or 8. Starter passes a signal to Engine (to turn the motor 
on). Body of Car also can be referred to as Framie. 

The following is a Document Type Definition (DTD) for the domain knowl- 
edge in XML, which defines the formal semantics of the domain-specific knowl- 
edge while retaining proper expressive power. 
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<! ELEMENT system (component I relation) *> 

<! ELEMENT component (amount?, unit?, (subcomponent I relation) *) > 
<! ELEMENT subcomponent amount?> 

<! ELEMENT amount EMPTY> 

<! ELEMENT unit EMPTY> 

<! ELEMENT relation EMPTY> 



<!ATTLIST system name CDATA #REQUIRED> 

< ! ATTLIST component name CDATA #REQUIRED> 

<!ATTLIST subcomponent name CDATA #REQUIRED type CDATA #IMPLIED> 
<! ATTLIST amount type CDATA "exactly" value CDATA #REQUIRED> 

<! ATTLIST unit name CDATA #IMPLIED type CDATA #REQUIRED> 

<! ATTLIST relation with CDATA #IMPLIED type CDATA #REqUIRED value 
CDATA #IMPLIED> 



Note that the domain-specific knowledge in XML for the translation doesn’t 
have to describe the domain exhaustively. Namely most of the elements and 
attributes are optional and attribute values can be any character strings. For 
example, the relationship element can represent inheritance, acronyms, message 
passing, etc. The minimum information required to guide the translation would 
be sufficient with the possibility of adding on more information later when nec- 
essary. 

The domain knowledge for our CARA example is shown as follows. 

<system name = "CARA system" > 

<component name = "Computer Assisted Resuscitation Algorithm"> 
<subcomponent name = "Display"/> 

<subcomponent name = "Button"/> 

<subcomponent name = "Pump Software System"/> 

<subcomponent name = "MAC"/> 

<relation with = "System" type = "hypernym"/> 

<relation with = "Software" type = "hypernym"/> 

<relation with = "Algorithm" type = "hypernym"/> 

<relation with = "CARA" type = "acronym"/> 

</ component> 

<component name = "Patient"/> 

<component name = "H0ST"> 

<subcomponent name = "Pump"/> 

</ component> 

</ system? 

The above specification describes that the whole system is composed by 
Computer Assisted Resuscitation Algorithm, Patient, and HOST. Computer 
Assisted Resuscitation Algorithm is a type of Algorithm, Software, or 
System that can be abbreviated as CARA. 

In the natural language documents one concept can be represented by many 
different ways making the translation hard to cluster similar information to- 
gether. These can be acronym, synonym, and hypernym. From the CARA ex- 
ample, the word Computer Assisted Resuscitation Algorithm’ is interchangeable 
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with ‘Algorithm’ or ‘CARA’. By using a minimum set of representative words 
that describes the entire components in the domain-specific knowledge, one-to- 
many relations between words and their various representations can be obtained 
and thus provides a simpler source to translate. The full set of words in the 
requirements documents are mapped into the minimum set of representative 
words by measuring similarity among words. The hypernym and the location of 
the common words are used for this estimation. 

In summary, by specifying domain-specific knowledge in XML and limiting 
the scope of the knowledge, the effort needed to build up the domain knowledge 
for the translation can be greatly reduced. 

5 Conversion from XML to Knowledge Base 

The raw information of the requirements document in natural language is not 
in the proper form to be used directly because of the ambiguity and implicit 
semantics in the document. Therefore an explicit and declarative representation 
(knowledge base) is needed to represent, maintain, and manipulate knowledge 
about a system domain [17]. Not only does the knowledge base have to be expres- 
sive enough to capture all the critical information but also it has to be precise 
enough to clarify the meaning of each knowledge entity (sentence). In addition, 
the knowledge base has to reflect the structure of TLG into which the knowledge 
base is translated later. 

The knowledge base isn’t a simple list of sentences in the requirements doc- 
ument. The linguistic information of each sentence such as lexical, syntactic, 
semantic, and most importantly discourse level information has to be stored 
with proper systematic structure. 

Each sentence of the requirements documents has to be represented in a way 
that eases the interpretation of the sentence. In computational linguistics this is 
done by constructing a parse tree of the sentence, which contains the syntactic 
information of the sentence. By using this semantic information we can tell what 
type of operation a certain object executes on other objects. 

To build a parse tree, each sentence in the requirements document is read by 
the system and tokenized into words. At the syntactical level, the part of speech 
(e.g. noun, verb, adjective) and the part of sentence (e.g. subject and object) 
of each word are determined by standard parsing techniques [8]. The corpora 
of statistically ordered parts of speech (frequently used ones being listed first) 
of about 85,000 words from Moby Part-of-Speech II [18] are used to resolve the 
syntactic ambiguity when there is more than one valid parsing tree. The system 
is able to handle elliptical compound phrases, comparative phrases, compound 
nouns, and relative phrases to allow the natural language in the requirements 
documents to be less controlled thus more natural. 

Also the anaphoric references (pronouns) in a sentence are identified accord- 
ing to the current context history. A pronoun can represent a word, sentence, or 
even context. It is worthwhile to mention here that the requirements documents 
are easier to process than other types of textual documents in the sense that usu- 
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ally requirements documents have well defined structures with less ambiguities 
and infrequent use or narrow reference scope of pronouns. 

Once the references of pronouns are determined, each sentence is stored into 
the proper context in the knowledge base. The structure of knowledge base re- 
flects the structure of the requirements in XML. The meta attribute information 
from XML is also stored in the knowledge base to be used for the translation from 
knowledge base into TLG. If no meta attribute or data structure is specified in 
the requirements in XML, the system totally relies on the linguistic information 
in the document to build the knowledge base according to the context. For more 
information on this process, we refer the readers to [19]. A part of the CARA 
knowledge base is shown in Figure 2. The knowledge base of CARA system con- 
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Fig. 2. Knowledge base for CARA. 



tains the meta information from the XML requirements in its tree-like structure 
as well as the linguistic knowledge. 

In summary, the knowledge base stores not only the linguistic information 
of each sentence but also the data structure and meta information of related 
sentences as specified in the requirements in XML. Along with this process, 
linguistic ambiguity is detected and resolved in parsing and construction of the 
knowledge base. 

6 Transition from Knowledge Base to TLG 

Two-Level Grammar (TLG) may be used to achieve translation from an infor- 
mal NL specification into a formal specification. Even though TLG has NL-like 
syntax its notation is formal enough to allow formal specifications to be con- 
structed using the notation. It is able not only to capture the abstraction of the 
requirements but also to preserve the detailed information for implementation. 
The term “two level” comes from the fact that a set of domains may be defined 
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using context-free grammar, which may then be used as arguments in predicate 
functions defined using another grammar. TLG may be used to model any type 
of software specification. The basic functional/logic programming model of TLG 
is extended to include object-oriented programming features suitable for modern 
software specification [20]. The syntax of the object-oriented TLG is: 

class Class_Name. 

Data_Name {, Data_Name} : : Data_Type {, Data_Type}. 

Rule_Name : Rule_Body •[, Rule_Body}. 
end class [Class_Name] . 

where the term that is enclosed in the curly brackets is optional and can be 
repeated many times, as in Extended Backus-Naur Form (EBNF). The data 
types of TLG are fairly standard, including both scalar and structured types, as 
well as types defined by other class definitions. The rules are expressed in NL 
with the data types used as variables. Further details about the TLG language 
may be found in [9]. 

The conversion from the knowledge base to TLG flows very nicely because 
the knowledge base is built with the structure taking this translation into con- 
sideration. The root of each context tree becomes a class. And then the body 
of each class is built up with the sentence information in the sub-contexts of 
the root. Gombined with the specification in the domain-specific knowledge, the 
knowledge base of the GARA example would be translated into the following 
TLG specification. 

class Mode. 

HOST , MAC , Pump : : Component . 

Pump_Sof tware_System : : Software . 

Blood_Pressure_Sensor :: Sensor. 

Patient : : Person. 

Secondary _Display, Pause_Button :: Interface. 

Automatic_Servo-control_Start_Button :: Interface. 

Hardware_Setting : : Setting. 

Occlusion, Airlock_Logic_Levels :: Float. 

Back_EMF, Fluid_Impedance , Infusion_Rate :: Float. 

Clean_Blood_Pressure_Signal : : Float . 

Resuscitation, Infusion_Pumping : : Undefined. 

Prescribed_Blood_Pressure_Setpoint : : Undefined. 

IV_Infusion, Standalone_Mode : : Undefined. 

main : 
wait state ; 
manual state; 
autocontrol on state; 
autocontrol paused state. 
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wait state: 

HOST be powered up, 

Pump_Sof tware_System be available, 

Patient be placed onto HOST, 

Pump Cable be connected to HOST, 
while true then 

if Pump be infusing Fluid into Patient then 
break, 

HOST provide Power for Pump 
endwhile . 

manual state: 

Pump_Software_System detect Pump_Connection, 

Pump_Sof tware_System monitor Occlusion and Airlock_Logic_Levels , 

Pump Display be brought to Secondary_Display , 

Pump_Sof tware_System detect Back_EMF and Fluid_Impedance , 
Pump_Software_System begin to log Infusion_Rate , 

Pump continue to operate on Hardware_Setting, 

Blood_Pressure_Sensor be connected to Patient, 

Pump_Sof tware_System detect Clean_Blood_Pressure_Signal , 

Pump_Sof tware_System activate Automatic_Servo-control_Start_Button. 

autocontrol on state : 
if Start_Button be pressed then 
MAC control Pump, 

MAC begin Resuscitation to Prescribed_Blood_Pressure_Setpoint 
endif . 

autocontrol paused state : 
if necessary to pause MAC then 
Pause_Button be pressed, 
cause Infusion_Pumping to cease 
endif , 

while true then 

if Patient be removed from HOST then 
Blood_Pressure_Sensor be removed from Patient, 

Pump Cable be removed from HOST, 

allow Pump to continue operating in Standalone_Mode , 
allow IV_Infusion to be discontinued, 
break 
endif 
endwhile . 

end class . 

The main function will execute all 4 state functions (wait state, manual 
state, autocontrol on state, autocontrol paused state) nondeterministi- 
cally, indicated by separating these by semicolons (;) whereas a comma (,) implies 
sequential composition. However preconditions (pre_cond) in each state will be 
used as guarded statements to determine which state the system is currently in. 
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For each state function, first the preconditions will be checked. If all the precon- 
ditions are met, pre_exec statements are executed once. If there is a while loop, 
exec statements are executed. break_exec and break_cond statements are used 
for the system to break out this loop. If there are any post_exec statements, 
they are executed before returning from the function. 

The TLG code is translated into VDM-I--I- by data and function mappings 
(for more details on this translation we refer the readers to [9]). Once we have 
translated the TLG specification into a VDM-I— I- specification we can convert 
this into a high level language such as Java^^ or G-l— b, using the code generator 
that the VDM-I— I- Toolkit^^ provides. Not only is this code quite efficient, but 
it may be executed, thereby allowing a proxy execution of the requirements. This 
allows for a rapid prototyping of the original requirements so that these may be 
refined further in future iterations. Namely the inconsistencies, contradictions, 
and ambiguities hidden in the informal description can be discovered in the 
formal representation using the VDM-I— I- Toolkit. Another advantage of this 
approach is that the VDM-I— I- Toolkit also provides for a translation into a 
model in the Unified Modeling Language (UML) using a link with Rational 
Rose^“. 

7 Contribution and Conclusion 

This research project is developed as an application of formal specification and 
computational linguistic techniques to automate the conversion from a require- 
ments document written in NL to a formal specification language while assisting 
the developers with repetitive tasks. The knowledge base is built up from a NL 
requirements document in XML in order to capture the contextual information 
from the document while handling the ambiguity problem and to optimize the 
process of its translation into a TLG specification with aid of domain-specific 
knowledge in XML. Due to its NL-like flexible syntax without losing its formal- 
ism, TLG is chosen as a formal specification to fill the gap between the different 
level of formalisms of NL and formal specification language. 

The system is working for some small examples such as the requirements 
for an Automatic Teller Machine (ATM), with associated banking system do- 
main knowledge. For various, more complex, requirements documents, such as 
the GARA Infusion Pump Gontroller, the system has been useful in identifying 
problems and ambiguities with such specifications and in identifying additional 
information necessary to complete the implementation. It is expected that the 
technology we are developing will be able to produce implementation for these 
requirements documents as well, once the problems identified are corrected. 

This system is a very useful tool to assist software engineers in moving from 
the requirements document to the formal specification. Our future work is to 
continue developing the system to improve system usability and robustness with 
respect to its coverage of requirements documents. When finalized, it is expected 
that by using the formalized context in NLP and TLG as a bridge between the 
requirements document and a formal specification language, we can achieve an 
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executable and reusable NL specification for a rapid prototyping of require- 
ments, as well as development of a final implementation assisting the developers 
throughout the software development life cycle. 
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Abstract. The paper describes a formal framework for designing and 
reasoning about resource-constrained systems. The framework is based 
on a series of process algebraic formalisms which have been previously 
developed to describe and analyze various aspects of real-time communi- 
cating, concurrent systems. We develop a uniform framework for formal 
treatment of resources and demonstrate how previous work fits into the 
new framework. 



1 Introduction 

An embedded system consists of a collection of components that interact with 
each other and with their environment through sensors and actuators. Em- 
bedded software is used to control these sensors and actuators and to provide 
application-dependent functionality. Two important distinguishing characteris- 
tics of embedded applications are limited resources (processing power, memory, 
network bandwidth, power consumption, etc.) and the hybrid (discrete and con- 
tinuous) nature of behaviors. Many embedded systems are part of safety-critical 
applications, e.g., avionic systems, manufacturing, automotive controllers, and 
medical devices. 

There are two major factors that complicate the design and implementation 
of embedded systems. First, the software complexity of embedded systems has 
been increasing steadily as microprocessors become more powerful. To mitigate 
the development cost of software, embedded systems are being designed to flex- 
ibly adapt to different environments. The requirements for increased functional- 
ity and adaptability make the development of embedded software complex and 
error-prone. Second, embedded systems are increasingly networked to improve 
functionality, reliability and maintainability. Networking makes embedded soft- 
ware even more difficult to develop, since composition and abstraction principles 
are poorly understood. 
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A natural response to the increasing complexity of embedded systems de- 
velopment is an increased emphasis on model-based development of embedded 
software. Models can be constructed for embedded systems and their properties 
can be analyzed through simulation and model checking. Models can be used to 
generate code skeleton and task structures and then platform dependent code 
can be added to work on specific environment. Since it may not be possible to 
completely automate code generation, models can be used to validate implemen- 
tation. One way to do this is to use a design model for generating test suites, 
and then, use them to check the conformance of an implementation to design 
specifications. Another way is to extract models from legacy code and use them 
to validate the code with respect to specifications. The third way is to ensure 
that the implementation is correct at runtime through monitoring and checking 
of the behavior of the running system. For safety critical embedded systems, it is 
important to have assurance that such systems are reliable. It is well-known that 
activities related to certification of such systems (e.g., avionics, medical devices) 
are extremely time consuming and costly. Model based development can be tai- 
lored to facilitate certification processes adopted by various regulatory agencies 
such as FAA and FDA. 

Figure 1 provides an overview of the model-based development framework be- 
ing developed at the University of Pennsylvania. From the model of an embedded 
system specified as hybrid system, the code generator produces a set of tasks as 
well as code for the tasks. Given the end-to-end timing requirements of the em- 
bedded system and the description of the target hardware and operating systems 
platform, the timing estimator identifies the periods and deadlines of the tasks. 
These timing parameters are chosen to guarantee the end-to-end constraints, but 
the execution times of the tasks are not yet determined. The resource modeler 
takes the communication and synchronization structure of the generated tasks 
and tradeoffs between code size and execution as input and generates possible 
resource-aware models. From the models, the schedulability evaluator estimates 
the worst-case execution times and then identifies which models can be executed 
with their timing parameters under the available resource limits. If no such so- 
lution exists, the timing parameters of the tasks are readjusted and the design 
process is repeated. 

In this paper, we limit our discussion to the general resource framework for 
embedded systems, which provides a formal semantical foundation for under- 
standing resource-constrained behaviors subject to real-time constraints, mem- 
ory limitations, power consumption, etc. The notion of a resource plays a cen- 
tral role in the specification and design of embedded systems, where execution 
is subject to a large number of resource constraints, such as timing, power con- 
sumption, size and weight, etc. We feel that, in order to properly specify and 
analyze such systems, a modeling formalism should incorporate the notion of a 
resource as a first-class entity. 

Related work in the area of resource handling in embedded real-time systems 
falls into two categories. On the one hand, the importance of the issue has been 
long realized by practitioners and a number of model-based, albeit informal, ap- 
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Fig. 1. Overall structure of model-based development framework. 



proaches have been published. We mention [13,16,9,3,2] among many others. On 
the other hand, several formal approaches have emerged that aim at scheduling 
of sets of tasks under constraints. For the most part, these approaches consider 
only timing constraints and do not introduce the notion of resource, implicitly 
considering the processor as the only shared resource in the system. For exam- 
ple, the authors of [8] propose a formalism that allows us to model preemption 
in asynchronous real-time systems. In [4], the authors limit themselves to fixed- 
priority scheduling approaches, which allow them not to consider preemption 
directly, accounting for it in the worst-case computation time. The formalism 
of [6] provides a general scheme for handling preemption of processes due to 
resource contention, but the scheduling rules have to be encoded by modifying 
transition rules in the formalism (effectively creating a custom formalism for 
each scheduling policy). A different approach is taken in [1], where the authors 
view the scheduling activity as control and use controller synthesis techniques 
to model scheduled real-time systems. 

In our previous work, we have proposed a family of process-algebraic for- 
malisms for modeling and reasoning about resource-constrained systems (see [11] 
for an overview). The family is built around ACSR, a discrete-time process 
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algebra. Extensions and variations include Dense-time ACSR that includes a 
more general notion of time; ACSR- VP that includes a value-passing capability; 
PACSR, a probabilistic formalism for quantitative reasoning about fault-tolerant 
properties of resource-bound systems; P^ACSR [12] that allows to specify power- 
constrained systems. The PARAGON toolset [18] provides tool support for mod- 
eling and analysis using these formalisms. 

The family of process algebras all share the modeling approach, where a sys- 
tem is modeled as a collection of communicating concurrent processes. Operators 
to express structure of a process are also very similar in all of the formalisms. 
The difference lies in the way resources are used and the attributes they carry. 
For example, in PACSR resources have an attribute that captures the prob- 
ability of failure for the resources. In ACSR-VP we can have tuples of data 
values associated with a resource that may be manipulated during execution, 
and P^ACSR introduces power consumption attributes. In each formalism, the 
set of resource attributes and the way the attributes are manipulated are slightly 
different. This makes it difficult to systematically present the formalisms. More 
importantly, each extension required changes to the PARAGON toolset that 
have to be implemented in an ad hoc every time a new extension is made. 

The main aim of this paper is the development of a general process algebraic 
framework to facilitate the construction of system models that allow us to cap- 
ture faithfully all of their relevant functional and non- functional requirements. 
The framework allows to represent all the formalisms in the ACSR family and 
provide for easy incorporation of new features both into the formalism and the 
supporting toolset in a uniform manner. The paper presents the formal definition 
of the framework and demonstrate how to capture existing formalisms within 
the framework as well as create new ones. 

2 The Framework 

We define a process-algebraic formal framework for reasoning about real-time 
systems. The basic entity of the framework is that of a resource. We assume 
that a system contains a finite set of reusable resources drawn from a countably 
infinite set of resources TZ. Resources can correspond to physical entities, such 
as processor units and communication channels, or to abstract notions such as 
message arrival. 

A resource is characterized by a set of attributes that let us capture aspects of 
the resource’s behavior depending on the needs of the application, such as timing, 
probabilistic, or communication behavior, or, priority and power consumption 
during resource usage. Resources are partitioned into classes TZi, . . . , with all 
resources in a class having the same attributes. In turn, an attribute may have 
one or more elements; an attribute, a, with n elements is specified as a tuple 

a: {Ti : kindi, . . . ,T„ : kind„) , 

where Ti,...,T„ are basic types such as integers, characters, tuples, etc, and 
kindi, ..., kind„ G {static, dynamic} define whether the value of the attribute’s 
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element remains constant throughout computation (static) or is associated to 
every resource use (dynamic). 

Example 1. As an example, consider the class of resources TZf that may experi- 
ence failures, consume power, and whose use is regulated by priorities. We may 
characterize this class by three attributes as follows: 

TZf : [tt : ([0, 1] : static), pc : {int : dynamic), pr : {int : dynamic)]. 

Attribute tt captures the possibility of resource failure. It has one element, that 
of the probability of failure, which is assumed to be constant throughout all 
executions of the resource. Attribute pc is the power consumption, which may 
be different in each resource use depending on the level of power required on 
each occasion, and pr is the priority of a resource access, which may also be 
different depending on which process uses r. 

When writing a model in the framework, given a resource r, we specify the 
values of all of the static elements of its attributes, and then, whenever r is 
used in the model, it is accompanied by values for all of the dynamic elements 
of its attributes. Furthermore, we write ar{i) for the tth element of attribute 
a of resource r. Given resources cpu and chan in the resource class TZf, we 
specify once initially that, for example, TTr{cpu) = 0.01 and TTchan{T) = 0.1. 
Then, whenever each of the resources is used in the model, we give the values 
of its dynamic attributes in a resource access, for example, (cpu, 2.5, 1). We will 
always assume positional correspondence between the dynamic attribute names 
in the attribute tuple of a resource class and the values of attributes in the 
resource use. Therefore, in (cpu, 2.5, 1), pc = 2.5 and pr = 1. Resource accesses 
are specified in actions. An action A is a collection of resource accesses. By p{A) 
we denote the multiset of names of resources used in A. Actions are building 
blocks for processes. 

Syntax. We let P, Q range over processes, A ranges over actions, and / ranges 
over sets of resources. The following grammar describes the syntax of processes 
and actions. 



P ::= NIL I A : P I P + Q I P\\Q \ [P]i \ P\\I 
A .. — . . . , , OjYil ; • ■ • 7 ^mrim ) } 

Process NIL represents the inactive process. Process A : P, is the prefix operator: 
it executes action A and proceeds to P. Process P+Q represents a nondetermin- 
istic choice between the two summands. Process PjjQ describes the concurrent 
composition of P and Q: the component processes may proceed independently 
or interact with one another while executing actions. The construct [P]i, I QTZ, 
referred to as resource closure, produces a process that reserves the use of re- 
sources in / for itself, extending every action A in P with resources in J — p( A) . 
Finally, P\\I, referred to as resource hiding, allows the process to hide or restrict 
the identity of resources in I so that they are not visible on the interface with 
the environment of process P. 
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Example 2. As an example of a process, consider 

P {{cpu, 3, 2), {chan, 1, 0)} : P\ + {{cpu, 1, 1)} : P 2 . 

where resources cpm and chan are drawn from the resource class TZ of Example 
1. Process P represents a processor that can accept messages from a channel. 
We assume that reading the message from the channel requires additional power 
than remaining idle. Depending on whether the message arrives or not, P has 
two alternative behaviors. If the message arrives, as described in resource access 
{chan, 1,0), the processor may receive the message, consuming 3 units of power, 
and proceed to process it as Pi. Otherwise, the processor consumes only 1 unit 
of power and continues as P 2 ■ 

Semantics. The semantics of the framework is given operationally by a tran- 
sition system that captures the behavior of processes. It is based on the notion 
of a configuration which comprises of a process and a world/state that can be 
used to keep useful information about the resources of the process. We write 
C for the set of all configurations and we write S{P) G C, for a configuration 
containing process P in state S. Finally, we write Act for the set of all actions a 
configuration can engage in. The semantics is based on a function 

F{C,Act) — ^ 2'^ 

which, given a process configuration S{P) and an action A, returns the set of 
configurations that can be reached from S{P) by performing action A. Thus, 
the semantics is based on the following rule: 

S'{P') e F{S{P),A) 

S{P) A S'{P') 

Domain Specialization. In order to adjust the general framework for the 
needs of a specific application domain, we must give meaning for resources and 
their attributes and establish the semantics for the processes. The following steps 
are needed to perform the specialization for a particular domain. 

— Resource classes. A finite set of resource classes need to be established for 
the domain along with the attributes of the class. 

— Syntactic consistency. A predicate valid must be provided. For a given action 
A, valid{A) denotes that the action can be legitimately used in a model 
within this domain. Furthermore, we may restrict the domain for the set of 
resources / appearing in process constructs [P]i and P\\I. 

— Semantic interpretation. Finally, the set C of configurations has to be defined 
and the function F has to be given. 

3 Framework Instantiations 

In this section, we will show how to instantiate the general framework to several 
progressively more complex domains. 




240 Insup Lee, Anna Philippou, and Oleg Sokolsky 



3.1 CCS 

The first domain we consider is the CCS domain [14]. CCS processes consider 
only communication constraints between concurrent processes. The actions that 
processes can engage in are send or receive messages on named channels. In 
addition, there is a silent action denoted r. A send action and a receive action on 
the same channel can synchronize to produce a silent action, whereas the silent 
action cannot synchronize with any other action. We introduce two resource 
classes, TZi and TZ 2 - The class TZi has one attribute polarity of type ({!,?} : 
dynamic). The class Ti -2 does not have attributes and contains the single resource 
r. As a shorthand, and to coincide with CCS style, we write r! for {(r, !)}, the 
send action on resource (channel r), r? for {(r, ?)} the receive action on channel 
r and r for {(r)} the silent action. 

The consistency predicate for an action A stipulates that A is valid if and 
only if p{A) is a singleton. Finally, we require that in [P]i, I ranges from the 
empty set of resources, i.e. the process construct is disabled, whereas in P\\I, 
I can be any subset of the resource class TZi, that is, we can only hide named 
channels. 

The process does not need any additional state information (S{P) = P), and 
the semantic function is defined recursively on the process structure, following 
the standard CCS approach. We begin by considering how actions interact with 
the process constructs. Let A and B be well-formed actions and I C 7?.i, then 
we define: 

ii{A,B} = {a?, a!} 
otherwise 

if p{A) i I 
otherwise 

Consequently we have that two actions may be composed in parallel to produce 
the silent action if they are send and receive actions on the same channel, and 
that an action can survive the hiding operator only if does not involve a resource 
from set I. 

We may now define the semantic function F as follows, where -I- stands for 
summation mod 2. 



F{A:P,A) = {P} 
Re F{Pi + P2,A) 


^ff 


3i G {1,2} such that R G F{Pi,A) 


ReF{P4P2,A) 




(Pi P2 A = Ai||A2, 


ReF{P\\I,A) 




R = P( P 2 ) or (3i G (1, 2} such that 
P/gP(Pi,A),P = P'|]P,+i) 

R' G P(P, P), A = P\\/, R = R'\\I 




3.2 ACSR 

ACSR can be viewed as an extension of CCS with time-consuming steps and 
priorities. We add a new resource class TZ^ with the attribute time of type 
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{int : static) and specify that for any resource r € TZs, timer = 1- That is all 
time-consuming actions take one unit of time. In addition, all three classes have 
the attribute priority of type {int : dynamic). 

The consistency predicate states than an action A is well-formed if the re- 
sources occurring in A, p{A), are pairwise distinct and, satisfy either p{A) C TI 3 , 
in which case they are referred to as timed actions, or p{A) = {r}, r € TZi U T^- 2 , 
in which they are referred to as instantaneous events. We write T>fi for the set of 
timed actions and T>e for the set of instantaneous events. As before, we omit the 
set brackets from actions involving resources in TZ\ U7^2) and simply write (a!,p) 
and (a?,p) for send and receive actions along channel a. Further, we specify that, 
in [P]i, I € 2^3, and that, in P\\I, I G 2^^ U 2^^. 

We now proceed to give the semantic function for ACSR. This is similar to the 
one in the CCS domain, except that it handles timed actions and, further, applies 
the preemption relation which specifies when two actions are comparable with 
respect to priorities. For example, 0 ^ A for all A G Vji, that is, the idle action 0 
is preemptable by all other timed actions, and (a,p) -< (a,p'), whenever p < p' . 
For the precise definition of ^ we refer to [10]. 

There is no state information and the definition of the semantic function is 
similar to that of CCS. We begin by describing the composability of actions 
with the various operators. Let A and B be well-formed actions, I G 2^^, and 
J G 2''^! U2''^L then 





r (t,p + p'), 


if {A,B} = {(a?,p),(a!,p')l 


A\\B=\ 


AUB 


if A, B G T>r, p{A) n p{B) = 


1 


u, 


otherwise 


[A]/ = j 


f Au {(r,0) 1 r G / - p(A)}, 

1 


if A G ©H 
otherwise 




r {{r,p) G A 1 r ^ J}, 


if A G Pfi 


A\\J = 


A, 


tag T>e, p{A) ^ J 


1 


U, 


otherwise 



We point out that two timed actions may be composed together only if the 
resources they access are independent from each other, that is, they do not 
compete for the use of any common resources. In case of the contrary, A\\B = T, 
signifying that a deadlock arises. [A]/ and A\\I capture the informal explanation 
of the process constructs \P]i and P\\I, respectively. The former ensures that 
access to resources I is reserved for process P by employing all of the resources 
r G I — p{A) at priority level 0. As a result any further sharing of the resources 
in I, with any parallel process of P, is prohibited (see the definition of A||i3). 
The latter disables any instantaneous events involving a channel in / and hides 
the use of /-resources from timed actions. 

We proceed to define function F. We let A, B range over the set of actions 
Act of ACSR, consisting of timed actions and instantaneous events. 



3i G {1, 2} such that R G F{Pi, A) 
and, if Pi+i A-/ B 



F{A:P,A) = {P} 
RGF{Pi+P2,A) iff 
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ReF{Pi\\P2,A) iff 



ReF{[P]i,A) iff 

RgF{P\\I,A) iff 



[{Pi G F{P^,Ai), Pi G F{P2,A2), 

A = A4A2,R^Pi\\Pi) 
or {A G Pe, and 3i G {1, 2}- 
P' G F{Pi, A) and R = P/||Pi+i)] 
and, if 3i G {1,2}- Pi B G Ve 

or Pi A, P 2 P = B 1 IIB 2 , 
then A-/. B 

R! G F{P,A'), R = [R']i, A = [A']i 
and, if P then A-f [B]i 
R' G F{P,A'), R = R'\\I, A = A'\\7, 
and, if P then A-f B\\I 



The first two rules define the semantics of the prefix and summation opera- 
tors. The third rule describes the behavior of the parallel composition operator. 
This allows component processes to proceed independently or synchronize with 
one another with respect to instantaneous actions and forces processes to syn- 
chronize on timed actions, making timed transitions truly synchronous, in that 
a process only advances if both of its subprocesses take a step. By the definition 
of A 1 II 2 I 2 we have that only one process may use a resource during any time 
step. The next rule describes the behavior of the close operator: When a process 
is embedded in a closed context, such as [P]i, we ensure that there is no further 
sharing of the resources r G I — p{A) by employing all of these resources at 
priority level 0 (see definition of [A]/). Instantaneous events are not affected by 
the close operator. Finally, the rule for resource hiding establishes that the set of 
resources / is restricted from the interface with the environment. Note, that in 
all but the first rule, a side condition checks that the action in question cannot 
be preempted by any other enabled action of the process. 



3.3 PACSR 

The PACSR domain is aimed at fault-tolerance analysis of real-time systems. 
Resources are allowed to fail with a fixed probability during an execution. This 
is captured by extending TZ^ with an additional attribute tt of type ([0,1] : 
static), representing a probability. This probability captures the rate at which the 
resource may fail. To be able to reason about failed as well as non-failed resources, 
we also have the attribute status of type {{up^down} : dynamic). Intuitively, 
the process {(r, l,up)} : P will succeed in performing action {(r, l,ttp)} with 
probability and fail, becoming NIL with probability 1 — tt^. On the other 
hand, the process {(r, l,down)} : P will fail with probability tt^., exactly when 
the first process succeeds, and succeeds with probability 1 — TTr- The use of failed 
resources is useful when we need to specify recovery from failures. We adopt the 
following notation: for all r G JZs, we write (r,p), for {r,p,up)), and {f,p), for 
{r,p, down). 

The consistency condition for the PACSR domain is the same as for the 
ACSR domain, both in case of the validity predicate and in the case of the 
syntactic conditions for resource hiding and resource closure. 
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We continue to define the semantics function F for PACSR. As already 
mentioned, resources are associated with a probability of failure. Thus, the be- 
havior of a system has certain probabilistic aspects to it which must be re- 
flected in the operational semantics of the domain. For example consider action 
{{cpu, 2 ), {chan, 1 )}, where resources cpu and chan have probabilities of failure 
0 and 1/3, respectively, that is iTcpu = 1 and TTchan = 2/3. Then the action takes 
place with probability TTcpu ■ TTchan = 2/3 if both resources are up, and fails with 
probability 1/3 if either of the resources fails. Therefore, behavior of a given pro- 
cess P depends on the status of resources which are relevant to P. To capture 
information about resource status in the configuration we write S{P) for pro- 
cess P in state S, where S G 2^^ x {up, down} records the status of resources of 
P. Configurations are partitioned into probabilistic configurations, from which 
only probabilistic steps are possible that update resource failure information, 
and non-deterministic configurations, where the state of all relevant resources is 
known and transitions can be computed. 

The intuition for the semantics is as follows: for a process P, we begin with 
the configuration 0(P). As computation proceeds, probabilistic transitions are 
performed from configurations to determine the status of probabilistic resources 
immediately relevant for execution (denoted imr(P)) but for which there is no 
knowledge in the configuration’s world. Once the status of a resource is deter- 
mined by some probabilistic transition, it cannot change until the next timed 
action occurs. Once a timed action occurs, the state of resources has to be de- 
termined anew, since in each time unit resources can fail independently from 
any previous failures. Nondeterministic transitions (which can involve events or 
actions) are performed from nondeterministic configurations. Precise definition 
for imr(P) is given in [15]. 

Let S = {(ri, si), . . . , (r„, s„)} FTZs x {{up, down)} and I = {ri, . . . ,r„} C 
P 3 . We write 

P(*^) up ^ri ‘ rfoujn (f 

- W(/) = {{ri,si),...,(r„,s„)} I Si G {up, down}}, and 
~ res{S) = I. 

We partition the set of configurations into the sets of nondeterministic config- 
urations, Cn, and probabilistic configurations, Cp. We have that S{P) G Cn iff 
imr(P) — res{S) = 0, that is, there is no immediate resource of P whose status 
is not already recorded in S, and S{P) G Cp, otherwise. We proceed to define 
function P. 

S'{P) G F{S{P),£) 

F{S{A:P),A) = {S{P)} 

F{S{A:P),A) = {0{P)} 

Re F{S{Pi+P2),A) 

Re F{S{Pi\\P2),A) 

S'{Pi) G F{S{P 2 ),A 2 ), A = A 1 WA 2 , R = S'{P{\\P}) 
or A G Pe, and 



iff 


P G Cp, S” G 


W(imr(P) -res(S')), S' = 


^SVJS", 




and £ = p{S”] 


) 






iff 


S{A:P) gCjv' 


and A G Pe 






iff 


S{A:P) G Cn, 


AGS and A 1 


GPr 




iff 


S{Pi + P 2 ) G 


Cn, 3* G {1, 2} 


such that 


RGF{S{Pi),A) 




and if S{Pi+\ 


)^,A^B 






iff 


S{Pi\\P2)gC 


iv, and [ S' {Pf) 


G F{S{Pp 


)i Ai), 
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e {1,2}. S' (Pi) e F{S{Pi),A),R = S'{P'\\Pi+i) ] 
and, if 3i e {1, 2} • S{Pi) B£Ve 
or S{Pi) S{P 2 ) B = Bi\\B 2 , then B 
R € F(S([P]/), A) iff S{[P]i) € Cm, S'{Q) G F{S{P),A'), A = [A]i, 

R = ^'([Q]/), and, if S{P) then A^ [B]i 
R G F{S{P\\I), A) iff S{P\\I) G Cm, S'{Q) G P(S(P), A'), A = A'\\7, 

R = S'{Q\\I), and, if S{P) A then A^ B\\l 

Thus, given a probabilistic configuration S{P), with I the immediate re- 
sources of P for which the state is not yet determined in S, and S” G W(/), P 
enters the state extended by S" with probability p(<S"'). Note that configuration 
S{P) evolves into S'{P) which is, by definition, a nondeterministic configuration. 

Example 3. To illustrate the probabilistic transition relation, consider process 

P ='{(n,l),(r2,2)}:Pi + (e,l).P 2 



in the initial configuration 0(P). The immediate resources of P are {ri, r 2 }. Since 
there is no knowledge in the configuration’s world regarding these resources, the 
configuration belongs to the set of probabilistic configurations Cp, from where 
we have four probabilistic transitions that determine the states of ri and r 2 ' 



0(P) ^ ^ {fT,r 2 }(P), and 



0(p) 



All of the resulting configurations are nondeterministic since they contain full 
information about P’s immediate resources. 



The remaining of the rules concerning the nondeterministic configurations 
follow along the same lines as the ACSR rules. The only point to note concerns 
the prefix operator: for the timed action A to be performed by configuration 
5'(A : P), it must be that all resources in A are available in the configuration’s 
state. 



Example 4- Returning to the previous example, the nondeterministic configura- 

def 

tion {ri,r 2 }(P), where P = {(ri,2), (r2,2)} : Pi + (e, 1).P2 has two nondeter- 
ministic transitions: 

{ri,r 2 }(P) 0(Pi) and {ri, r 2 }(P) ^ {ri, r 2 }(P 2 ). 

The other configurations {ri,r 2 }(P), {rT, r 2 }(P), and {fT, r 2 }(P), allow only 
the e-labeled transition since either ri or T 2 is failed. 



4 Multi-capacity Resources and Memory Constraints 

In this section we use the resource framework to construct a formalism MCSR 
that captures memory use as a different kind of resource. Memory is a critical 
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resource in size-constrained embedded systems such as mobile phones. In the 
design of an embedded system, we need to consider tradeoffs between memory 
use and the speed of the tasks in the system. A task can be made to use less 
memory at the cost of executing longer. But this increased execution can violate 
timing constraints in the system. The proposed formalism will allow us to capture 
such tradeoffs and reason about their effects. 

We see that the nature of memory as a resource is different from other serially 
reusable resources considered so far in this paper. Two processes can use the same 
memory, as long as the total use does not exceed the memory capacity. Therefore, 
we introduce the new class of resources called multi-capacity resources. 

We develop MCSR as an extension of ACSR (see Section 3.2) by adding a 
new resource class, TZ^, of multi-capacity resources. We will use resources in this 
class to represent memories, however, other kinds of resources may be modeled in 
the same way. Each resource has two attributes. The first attribute, capacity of 
type {int : static), represents the capacity of the resource. The second attribute, 
use of type {int : dynamic), captures the memory used in a step of a process. 

The consistency predicate in this framework, extends that of ACSR by al- 
lowing multi-capacity resources to be used in timed actions of MCSR processes, 
so that for a timed action A, p(A) C TZ^ U7^4. The semantic function for MCSR 
is the same as for ACSR, except that the definition of action composition is 
modified as follows: 

if {A,B} = {{al,p), {al,p')} 
if A,B G Vr, {p{A) n p{B)) n T ^-3 = 0 and 
Vr G T^- 4 , (r, Ui,c) G A, (r, U2, c) € B ^ ui -h U2 < c 
otherwise 

The operator A 1+1 R, defined on compatible timed actions (meaning that 
A\\B yf T), is defined as follows: 

1. (r, tti, . . . , a„) GAl+lRifrGT^sU 7^4, (r, oi, . . . , a„) G A and r ^ p{B) or 
(r, tti, . . . , a„) G B and r ^ p{A), or 

2. (r, Ml -I- U2, c) G A l±l R if r G TZ^, (r, mi, c) G A and (r, U2, c) G R. 

Memory Aware Scheduling. We illustrate the use of MCSR by showing a 
collection of periodic tasks that execute within the same system, sharing the 
processor and memory. Each task is characterized by its period Pi and execu- 
tion time Ci- Each task is released for execution at the beginning of every period 
and its deadline is equal to the period. That is, a task has to use the processor 
for Ci time units in each interval [k * pi, (fc -I- 1) * Pi], for each integer k. Tasks 
are assigned a priority for accessing the processor, and an executing task can be 
preempted by a task with a higher priority. Each task has a fixed amount 
of memory allocated to store the code and static data structures. In addition, 
when the task is released for execution, an additional amount of memory, mi^di 
is allocated to the task for keeping its dynamic data. Once the task completes its 
execution in the current period, the dynamically allocated memory is released. 



f {t,P + p'), 
I A OR, 




246 Insup Lee, Anna Philippou, and Oleg Sokolsky 



To model such a task in MCSR, we adapt the approach of [7], extending it 
with additional resources representing memory consumption. To simplify pre- 
sentation, we assume that priorities of tasks are fixed, for example, according to 
rate-monotonic scheduling discipline. More complex dynamic-priority schedul- 
ing approaches, such as EDF, can be accommodated as well. An instance of the 
scheduling problem is modeled as a collection of processes Ti, . . . , T„. Process Ti 
is shown below. A task is represented as a parallel composition of two processes: 
Jobi and Activ atari. 

Ti = {Jobi\\Activatori)\\{starti} 

Activator i= {starti,i)-9^' ■ Activatori 
Jobi = {(wem, : Jobi + {start i,Q). Exec i^^Q 

Execi^e,t = e < Ci -^{{cpu, i), {mem, mi^c + rrii^d)} ■ Execi^e+i,t+i 
+ {{mem,mi^c + rrn^d)} '■ Execi^e,t+i 
+ e = Ci^ Jobi e G {O..Cj},t G {0..pi} 

The description of task Ti involves the use of three resources: starti G TZi, 
mem G 77-4 and cpu G TZs, the last two corresponding to the system’s processor 
and available memory. We assume a value M for the capacity of multi-capacity 
resource mem. The task consists of two processes running in parallel. The role 
of the activator is to keep track of the timing constraint of the task. At the 
beginning of every period, Activatori sends the signal starti to Jobi, releasing 
the task for execution, and then idles until the end of the period. If, by the end of 
the period, the task has not finished its execution, it will not be able accept the 
next starti signal, resulting in a deadlock alerting us to the scheduling failure. 

The other process, Jobi, upon receiving the starti signal, Jobi begins its 
execution. At each time step, the task has a fixed priority that is equal to the 
task index. When the task receives the processor resource, it executes for one 
time unit and its accumulated execution time e is increased together with the 
elapsed time t. At any time step, the task can be interrupted by another task 
that has a higher priority. In this case, the interrupted task executes a timed 
action that does not use the cpu resource, but retains its memory use. In this 
case, its accumulated execution time stays the same while the elapsed time is 
increased. 

Note that each job uses some amount of the memory resource mem in each 
step. However, this amount is different in different states of the task. While the 
job is waiting for the .starti signal in Jobi, it uses units of memory, and after 
the task is started, it uses mi,c + nvi^d units of memory, regardless of whether it 
is running or preempted. 

Code Size vs. Execution Time Tradeoff Modeling. In a recent paper [17], 
Shin et al. study a different problem that considers a tradeoff between code size 
(static memory use) and execution time. By choosing different encodings of the 
instructions sets, modern embedded processors offer the possibility to reduce 
the code size at the expense of a longer execution time. Each task can have 
its own encoding. However, increased execution time may render the task set 
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unschedulable, while increased code size may exceed the memory capacity. Thus 
we have to find an encoding for each task that will satisfy all the constraints. 
For a task i, the tradeoff is represented as a list of pairs where the 

first element is the code size and the second element is the respective execution 
time. The encoding is chosen statically before the task begins executing. 

We can address this problem with a modified task model shown below. Each 
task initially makes a non-deterministic choice from J possibilities, choosing its 
memory use rriij and execution time Cij . Since the memory use remains constant 
once the choice has been made, only the first step of the process JobStarti uses 
the memory resource. The rest of the job process consists of J disjoint copies of 
the process Jobi from the previous example, for the different values of c^j-. When 
the task processes are combined in parallel to represent the complete system, 
some of the initial choices become infeasible, exceeding the memory constraints. 
Of the initial choices that satisfy the memory constraints, some will violate the 
timing constraints during execution, resulting in a deadlock in the state space. 
Therefore, analysis will find initial steps that lead to deadlock-free subsystems 
to identify parameter values that satisfy both timing and memory constraints. 



Ti = { J ob Start i\\Activatori)\{starti} 

Activatori = {starti,i)-^^' '■ Activatori 
JobStarti = -Fj-g j{(mem, rriij)} : Jobij 
Jobij = 0 : Jobij + {starti,0).ExeCijfi^o 
Execij^e,t = e < Ci^j-^{{cpu,i)} : ExeCij^e+i,t+i 
-I- 0 : Execij^e,t+i 

6 = Cij — ^ Jobij e G {O..Cjj},t G {0..pi} 



5 Conclusions and Future Work 

We have presented a formal approach to the design of real-time embedded sys- 
tems, which explicitly captures resource constraints that affect the system be- 
havior. The approach includes an extension mechanism that allows us to easily 
incorporate new kinds of resources and resource constraints. We have shown 
how to model memory capacity constraints using multi-capacity resources. The 
resource-modeling formalism is incorporated into a larger model-based develop- 
ment framework for embedded systems. 

We are working to identify additional classes of resources and develop means 
of incorporating them into the formalism, as well as providing flexible tool sup- 
port for the model development in the formalism. Two interesting extensions 
to the current work are being considered. One is to go beyond serially reusable 
resources to consumable resources, which can be used only a fixed amount of 
times during a computation and possibly replenished after a certain amount of 
time passes. Such an extension will allow us to have a more natural treatment 
of battery-operated devices. The other direction is to explore whether stochastic 
process algebras (e.g., [5]) can be captured within our framework. 
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Abstract. Architecture Description Languages provide significant opportunity 
for the incorporation of formal methods and engineering models into the analy- 
sis of software and system architectures. A standard is being developed for em- 
bedded real-time safety critical systems which will support the use of various 
formal approaches to analyze the impact of the composition of systems from 
hardware and software and which will allow the generation of system glue code 
with the performance qualities predicted. The standard, the Avionics Architec- 
ture Description Language (AADL), is based on the MetaH language devel- 
oped under DARPA and US Army funding and on the model driven architec- 
tural based approach demonstrated with this technology over the last 8 years. 
The AADL standard will include a UML profile useful for avionics, space, 
automotive, robotics and other real-time concurrent processing domains includ- 
ing safety critical applications. The paper provides an overview of the concepts 
supported in MetaH and the AADL as examples of the architecture based model 
driven paradigm and notes several new model based approaches becoming 
available. 



The Need for an Industry Solution 

Complex embedded real-time systems are very expensive to develop, to maintain and 
to evolve. When system lifecycles are long compared with the commercial lifecycle 
of its components and when system capabilities must change to keep up with ad- 
vances, evolvability becomes a key component in reducing the cost of keeping sys- 
tems up to date. Families of systems also need a simple approach for evolving new 
members of the family from a baseline configuration. Component changes impact 
system performance in many areas such as speed, schedulability, reliability, and 
safety and must be made quickly and predictably against these cross cutting dimen- 
tions of system performance to keep costs reasonable. Predictive models in the past 
have been very difficult to apply due to the complexity and size of the systems and a 
lack of an approach which integrates the models with system development so that the 
models are updated with the system, accurately reflecting the implementation. 



A Solution with Potential for Radical Impact 

An architecture based, model driven approach provides the foundation to make com- 
puter based system changes and predict the impact. It provides analysis at the natural 
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level for change, the software and hardware component. Component level changes 
that affect system performance are represented through component attributes neces- 
sary to perform the system level analysis. Component level analysis is handed with 
separate tools, component level development is by conventional methods, hand coded, 
reused or generated. The challenge is to develop sound engineering models for a class 
of behaviors that are at the heart of large complex real-time systems. Some very help- 
ful models exist now that can be applied to system development. The benefit is the 
rapid construction to specification with predictable behavior for the development and 
evolution of trusted systems. An additional challenge is the extension of these con- 
cepts to new domains of system architecture. 

The capture of the architectural specification and the component attributes is ac- 
complished with an Architecture Description Language (ADL). The language must be 
capable of expressing the architectural requirements for the domain of application in a 
way that engineers working in the domain can easily specify and modify systems. The 
ADL and tools must permit partial specification to allow for early analysis and proto- 
typing, with incremental completion as additional information or analysis become 
available. Analysis must be efficient, adequate and automated so that it will always be 
performed. The analysis and system building capabilities must provide support in ma- 
jor areas of concern in the domain. The ADL must support multiple forms of analysis 
so that a change in a component or a change in the architecture can check multiple ar- 
eas of possible impact without changing to alternative specification languages. For in- 
stance, moving a component from one processor to another can impact scheduability 
on the bus, scheduability on the processor, system optimization, multi-level safety re- 
lationships and system reliability. 

The MetaH ADL and toolset provides such an environment. Our experience using 
MetaH over the last 8 years has convinced us that architecture based model driven 
approaches can revolutionize the development of real-time systems. 



Defining the Needed Models 

An engineering model is defined for the purposes of this paper as a body of knowl- 
edge that provides a clear and concise notation for describing significant system be- 
haviors; that applies to a broad class of systems within the domain; that provides re- 
peatable methods without custom tuning for producing good implementations; and 
that is supported by analytic methods to predict and verify behavior. These criteria 
were used in the development of the MetaH language and code generation to select 
the methods that would be applied to system architectural analysis. Examples of such 
methods are preemptive real-time scheduling theory, fault tree and Markov chain 
models, feed-back control theory, and real time message passing and timing models. 
These are widely used in successful engineering practice within the domain. Each was 
used in MetaH to define the language, construct the toolsets to analyze the specifica- 
tion and construct the code generator used to build the executive and to integrate the 
system. Additional key characteristics of these models are that the modeling approach 
can be supported by efficient code generation, necessary attributes can be determined 
or estimated to form profitable analysis, and that the models provide a bound for the 
designed system (schedulable processors and busses, mean time to failure, can affect 
higher level safety or security components when failing) that can be checked each 
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time the system is updated. Good engineering models are typically produced by a 
combination of theoretical and empirical work. 

Additional models, beyond foundational models that are reflected within the ADL 
itself, can be added. The emerging AADL standard (based on MetaH) permits exten- 
sion to the set of standard component attributes to enable the user or vendor to add 
new modeling approaches and analysis tools. For example, attributes can be extended 
to incorporate constraint analysis so that mathematical functions can be applied to in- 
sure that high level attributes are not exceeded by the composition of lower level 
component specifications. The European Space Agency in its experiments has used 
such constraints to add modeling of the weight of a satellite but they could be used as 
well for power and memory consumption. Attribute extensions could also be used to 
add additional types of dependency analysis, record or model the results of various 
types of safety analysis, provide for the assessment of various qualities of service and 
support new scheduling methods. Attribute sets developed by organizations may be 
contributed to the standardization committee for possible inclusion in future versions 
of the standard. 

Engineering models are essential for many of the “ilites” we desire in system de- 
velopment; scalability (adding processors, processes, devices, then understanding 
quickly the effect and generating the compliant glue code to integrate the system), 
evolvability (incrementally changing the architecture during development and over 
the lifecycle, reviewing the impact via checking the models, provides strong support 
for evolutionary development methods such as the spiral development approach), de- 
pendability (understanding the impact of composition of components with different 
fault models and the effect of fault tolerant approaches), composability, and reusabil- 
ity (providing a precise specification of component attributes so its fit may be ana- 
lyzed). Engineering models are an essential basis for requirement analysis, specifica- 
tion languages, and for tools to automate various development activities such as 
design analysis and code generation. 



MetaH as an Example 

Since our insight into model based real-time development is through MetaH, the fol- 
lowing sections provide some history, a high level overview and a comparison of the 
current typical development process to the model based process using MetaH. The 
paper also includes some data on the success of the approach. 



History 

MetaH was developed over two DARPA programs and has greatly benefited from ad- 
ditional funding from the Open Systems - Joint Task Eorce. The first. Domain Spe- 
cific Software Architectures (DSSA), was concerned with using domain specific sys- 
tem engineering knowledge to build Architecture Description Languages (ADLs) that 
could specify software architectures and analyze architectural properties. MetaH lev- 
erages the rapid construction of systems further by adding the automatic integration of 
hardware and software in accord with modeling used to analyze the system. The sec- 
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ond, the Evolutionary Design of Complex Systems (EDCS), was focused on our abil- 
ity to build systems that could be rapidly evolved with predictable impact. A third 
DARPA program, Dynamic Assembly for System Adaptability, Dependability and 
Assurance (D ASAD A) is leveraging MetaH as an embedded systems ADL. The Open 
Systems - Joint Task Eorce (OS-JTE) has supported analysis of open standards using 
MetaH as well as the standardization of the Avionics Architecture Description Lan- 
guage (AADL) based on MetaH. 

Dr. Steve Vestal of the Honeywell Technology Center has been the principal inves- 
tigator. Bruce Lewis has served as technical POC on both DARPA programs and has 
led the US Army Aviation and Missile Command, Research Development and Engi- 
neering Center, Software Engineering Directorate (SED) laboratory demonstrations 
and technology integration with MetaH since 1993. The US Navy, US Air Eorce, the 
Ada Joint Program Office, and the US Army Space and Missile Defense Command 
have also funded MetaH related projects. 



A High Level Overview 

The MetaH language provides a system designer a simple but precise language for 
specification of architectural requirements. Prom the specification, the toolsets extract 
the formal modeling parameters for multiple analyses. MetaH was designed to inte- 
grate the multiple domains of application software in avionics on a generated archi- 
tectural backplane based on formal scheduling and implementation methods while 
guaranteeing a hard real-time schedule. It comprehends both hardware and software 
components. It will generate the architecture integrating the hardware and software 
components into a system complaint with the modeled behavior. It provides a means 
to port hard real-time systems across execution environments rapidly. Current archi- 
tectural analyses include schedulability, reliability and safety/security. 

The language and toolset were developed to meet the requirements for building 
state-of-the-art modular multiprocessor systems with multilevel safety, security, and 
fault management. It provides for the specification and generation of dynamic multi- 
mode behavior across multiple processors under the real-time constraints of flight 
control. It also can build from the specification advanced space and time partitioned 
systems enabling very significant reductions (estimated at 80%) in re-validation and 
re-testing costs when changes are made to an avionics or mission critical system. The 
approach of using a combination of time and space partitioning is an emerging com- 
mercial avionics technology, now part of several fielded commercial avionics sys- 
tems. Space and time partitioning is also valuable in military systems for the same 
reasons, especially with the recent requirements on some military avionics systems 
for EAA certification. 



Model Based Development Process 

Model based development has many advantages over conventional software devel- 
opment and hardware / software integration. To illustrate this, we compare the current 
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software development approach to the approach we recommend based on MetaH’s 
capabilities for integrated modeling, architecture description, and system integration. 

Figure 1 shows the current typical software development paradigm with its specifi- 
cation of requirements and design in various media, case tools, prototypes, paper, dis- 
connected models, spreadsheets etc. Integrated Project Teams alleviate some of the 
communication problems in this “Over-The-Wall” approach, but this approach is 
characterized by specification for human interpretation and system construction. 
Evaluations of architecture may occur with requirements modeling tools and simula- 
tions but the results are reduced again to paper for impact on the final system soft- 
ware. Modeling results tend to be disconnected from the next phase and from each 
other. Multiple complex modeling languages are required, one for each system analy- 
sis area requiring high levels of expertise. Traceability of the models to the implemen- 
tation is usually rapidly lost during development. Integration of components into a 
system is manual and yet must be traceable to the models if they are used. Integration 
is often difficult, complex and very expensive. Code generation for system or compo- 
nent analysis is typically for prototyping and requirements are again specified for hu- 
man development of a traceable, testable integrated system. 



Current Software Process 




o 



0 








cy 



Implementation Integration 

Fig. 1. Manual, paper intensive, en'or prone, resistant to change 



Figure 2 shows the architecture based model driven approach [1][8][9] which pro- 
vides the ability to specify an architecture (consisting of software and hardware com- 
ponents, their interfaces and the system execution behavior), analyze its properties, 
populate it with source components, integrate hardware components, and then auto- 
matically build the system to the specification. First, using specified attributes for the 
hardware and software components and connections within and across processors, the 
architectural specification is used to model and analyze schedulability, reliability 
(fault handling), and safety/security dependencies. Modeling is incremental; the user 
fills out the attributes required for the modeling desired. For instance if safety level is 
not filled out for the components, the multilevel safety analysis is not performed. The 
analysis for each model is provided each time the architecture is modified and regen- 
erated so the impact can be noted in multiple areas of concern. The system is checked 
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against these models, warning the user if any used analysis is out of limits. Different 
versions of software or hardware components can be stored on the “bookshelf’ and 
easily substituted in the architecture. Architectural changes are easily made and ana- 
lyzed if the models for the components (as expressed as attributes of system level in- 
terest) are provided. 



Architecture Based Model Driven 
AADL Process 




Fig. 2. 

Additional model analyzers can be added as they are defined or improved to pro- 
vide modeling approaches which allow specification of more complex or larger sys- 
tems. We are currently working with the University of Illinois to increase the size of 
the reliability models we can analyze by two orders of magnitude. The AADL draft 
standard provides for attribute extension allowing users to add attributes and analyz- 
ers. 

For real-time architectures, the issues of schedulability, reliability and partitioning 
need to be understood early in safety and time critical systems [2] [4] [5] [8]. Once the 
systems engineer is satisfied with the architecture, the components can be developed, 
reused from another project, or generated in parallel with incremental automated inte- 
gration of the system with MetaH. The system is easily re-integrated through re- 
generation from the specification. Typically, early integrations may be on a work- 
station where behavior and system output can be validated. The final system would be 
automatically integrated from the specification and components, hardware and soft- 
ware, on the target platform where execution behavior and results can again be vali- 
dated. 

A major benefit is that the architecture and execution behavior specified is cap- 
tured, not in paper or the heads of the designers, or in scattered databases but in one 
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specification that integrates the final system and generates the executive that drives its 
execution. Also a single architectural specification is used for multiple formal analy- 
ses and therefore the system is generated compliant with each of the models used for 
analysis. 

If, in the process of development, the system needs to be changed, the specification 
is updated and the system is rebuilt. Specification changes allow scaling across multi- 
ple processors, adding new modes, changing the execution environment (new proces- 
sor(s), compilers, 0/S), moving processes across processors, tuning execution rates, 
message passing, event propagation, substituting new components, changing process 
interfaces, changing error models, safety or security levels, etc. Since the processor, 
buses, or other hardware devices are part of the architecture they can quickly be 
changed to any of a predefined set. The defined set is user expandable. Execution en- 
vironment dependencies reside in the toolset rather than the application code allowing 
rapid ports to new environments based on the toolset porting cost, not the size or 
complexity of the application. 

The systems engineer benefits from the power of the modeling approach without 
having to be an expert in it or having to implement the system in conformance to it 
manually. The timing and data movement semantics required to implement control 
applications are part of the semantics of the language. So are the elements required for 
execution and data movement for minimal latency. The engineer has to understand 
how and where to specify what he needs. He constructs the architecture by specifica- 
tion and analyzes the impact using the models provided. 



Evidence of Success 

The SED developed a generic missile architecture and used it to re-engineer the on- 
board software of an Army missile system. MetaH was used to specify the architec- 
ture interfaces and timing and to integrate re-engineered components and the dual 
80960 embedded hardware together to create an executable system [3]. In addition, a 
6 Degree of Freedom (6DOF) Software-In-The-Loop missile flight environment 
simulation was developed to allow us to evaluate flight characteristics. It was also re- 
engineered into MetaH so it could be executed in real-time. 

During this first development, the MetaH model based approach reduced the total 
effort to re-engineer the system and fly software-in-the-loop by 40 %. This estimate 
was made by our system and our hardware/software engineer, both of whom have ex- 
tensive experience in the design and construction of real-time systems. Given the pos- 
sible differences in skill level in dual implementation approaches, we believe this ap- 
proach gave us the best estimate. Their estimates are based on what it would have 
taken if they did the same task without the aid of the ADL and the associated toolset. 
We purposely made the estimate conservative. To further verify our estimates we pre- 
sented the work to several prime contractors, including the one who developed the 
missile system. They put the estimated savings at 66%. We later ported the applica- 
tion to several new execution environments. A single processor Aonix, Parr Lap OS, 
Pentium, dual Pentiums on VME, and a port using Green Hills, PowerPC and 
Vx Works. 
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Effort Saved Using MetaH With Port 

Total project 50%, Port Phase 90% 




Fig. 3. 

Our Software Engineering Directorate lab accomplished the MetaH toolset port in 
less than a week and the missile flew correctly in a simulation the first time it exe- 
cuted on the new embedded environment. Our estimated savings moved to 50% [9]. 

While the ADL significantly reduced the work in porting the application by captur- 
ing the real time specification and accurately reproducing the real time performance, 
it should be recognized that hardware oriented ports from a cost perspective are diffi- 
cult to predict. The risk of problems with hardware drivers, operating system inter- 
faces, compiler and 0/S incompatibilities and hardware bugs can always extend the 
cost. A low risk approach is to use the provided hardware targets in the toolset or have 
the tool vendor provide new targets. We did our own retargeting to demonstrate that it 
could be done. 

Since the missile architecture was not safety critical we did not experiment with 
the reliability and safety analysis. We expect that the savings provided by early analy- 
sis of reliability and safety partitioning will also provide significant benefit. Several 
studies of helicopter avionics architectures have been preformed by Honeywell. A 
significant avionics experiment using the additional modeling capabilities is needed, 
along with other complementary technologies, to demonstrate more convincingly the 
benefits. 



Rising Support for Architecture Based Model Driven Approaches 

Based on experience from a number of experiments and applications of the technol- 
ogy on various DARPA programs since 1993 and based on avionics and space re- 
quirements from industry, MetaH is being used as the baseline definition for the 
specification of the AADL under the Society of Automotive Engineers, Avionics Di- 
vision. See figure 4. 
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MetaH History 

1991 DARPA DSSA program begins 

1992 First partitioned target operational (Tartan MAR/i960MC) 
1994 First multi-processor target operational (VME i960MC) 
1998 Portable Ada 95, POSIX executive configurations 
Example evaluation and demonstration projects 

Missile G&C reference architecture (AMCOM SED) 

Missile Re-engineering demonstration (AMCOM SED) 

Space Vehicle Attitude Control System (AMCOM SED) 

Reconfigurable Flight Control (AMCOM SED) 

Hybrid automata formal verification (AFOSR, Honeywell) 

Missile defense (Boeing) 

Fighter guidance SW fault tolerance (DARPA, CMU, Lockheed-Martin) 

Incremental Upgrade of Legacy Systems (AFRL, Boeing, Honeywell) 

Comanche study (AMCOM, Comanche PO, Boeing, Honeywell) 

Tactical Mobile Robotics (DARPA, Honeywell, Georgia Tech) 

Advanced Intercept Technology CWE (BMDO, MaxTech) 

Adaptive Computer Systems (DARPA, Honeywell) 

Avionics System Performance Management (AFRL, Honeywell) 

Ada Software Integrated DevelopmentA/erification (AFRL, Honeywell) 

FMS reference architecture (Honeywell) 

JSF vehicle control (Honeywell) 

IFMU reengineering (Honeywell) 



Fig. 4. 



Both European and US companies/agencies are participating in the standardization 
effort. The standardization committee also has a liaison relationship with NATO’s 
Aviation Standard’s Committee and we informally coordinate with the Open Group 
and with UML committees as we have opportunity to attend the meetings. See figure 
5 below. 



AADL Standard Participants 



• Bruce Lewis: Chair, technology user 

• Ed Colbert: AADL & UML Mapping 

• Peter Feiler: Secretary, Co-author, Editor, technology user 

• Steve Vestal: MetaH Originator, Co-author 

Members 

• Boeing, Rockwell, Honeywell, Lockheed Martin, 
Raytheon, Smith Industries 

• NIST, NAVAir, OSJTF, British MOD 

• Dassault Aviation, Airbus, European Space Agency, 
COTRE 



Fig. 5. 

The same concepts that provide an Architecture Based Model Driven approach in 
MetaH will be part of the AADL. The standard provides a means for the commercial 
production of tools with a common AADL language interface. The UML profile, a 
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specialization providing AADL semantics, will allow the application of formal analy- 
sis and code generation tools through a UML graphical specification, enabling the use 
of currently available UML tools for specification. The UML profile is being devel- 
oped in parallel with the AADL standard and will be provided as an appendix. We 
also plan to provide an XML specification for the AADL language once the first ver- 
sion of the language standard is completed. These capabilities will provide an early 
interface for developing new analysis approaches and integrated use of toolsets. We 
will ballot the first version of the standard in December of 2003. 

The AADL Standardization Subcommittee also has a liaison relationship with a 
French research consortium, COTRE, headed by Airbus. COTRE has adopted the 
AADL for research into new tools, development and analysis methods to support 
aviation system development requirements. The AADL plays a significant role in a 
future software and systems development approach described by Airbus and COTRE 
in a recent paper[10]. Other US and European companies and agencies are evaluating 
and experimenting with MetaH or the AADL, including Euture Combat Systems. 

Architecture based, model driven approaches are also beginning to appear in the 
general software engineering domain. UML 2.0, the Model Driven Architectures Ini- 
tative [11], will provide a new layer to UML to directly support a generalized Model 
driven architecture based approach. See figure 6. It is expected that multiple profiles 
for different domains will be defined as specializations of UML 2.0. UML 2.0 is ex- 
pected to be released in mid 2003. The AADL UML profile will incorporate new ar- 
chitecture description capabilities from UML 2.0 when its released. The AADL UML 
profile will be based on UML 2.0. 

The Model Driven Architecture (MDA) 

Initiative 

• Based on the success of UML, the OMG has formulated a vision of a 
method of software development based on the use of models 

• Key characteristic of MDA: 

- The focus and principal products of software development are 
models rather than programs 

- “The design is the implementation” (i.e. UML as both a modeling 
and an implementation language) 

• UML plays a crucial role in MDA 

- Automatic code generation from UML models 

- Executable UML models 

- Requires a more precise definition of the semantics of UML 
(UML 2.0) 

Source: Bran Selic, Rational 



Fig. 6. 



The University of Southern California, Center for Software Engineering, lead by 
Barry Boehm, has announced the development of Model-Based Architecting and 
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Software Engineering (MBASE) approach [12]. This approach currently is being de- 
veloped to be compatible with several Architecture Description Languages, one being 
the AADL. 



Conclusions 

Initial demonstrations of the architecture based model driven approach with MetaH 
has shown significant promise for real-time avionics and related domains. Larger 
demonstrations and technology extension, including research and development of new 
modeling approaches will add to the paradigm’s power for rapid, low cost develop- 
ment and evolution of computer based systems. The power of the approach is strongly 
related the types of components and communications that can be described, to the 
models supported and to the automation of the system building process. The AADL 
Standard will significantly increase the power of MetaH to express architectures, ex- 
tendable attributes will support many new modeling approaches and the formalization 
of the language will still support an automated system build process. The UML pro- 
file will leverage existing UML toolsets and XML will ease toolset integration. The 
release of UML 2.0 will focus significant industry interest in the model driven ap- 
proach. Significant research into modeling focused on predicting system level proper- 
ties from component attributes is needed and can be significantly leveraged by Archi- 
tecture Based Model Driven methods to reduce the cost of system development and 
change. 
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Abstract. Systems of embedded systems (SoES) have been receiving a great 
amount of attention because of their capabilities of combining individual em- 
bedded systems to accomplish broad and common objectives. High confidence 
is critical for SoES since they are widely used in the fields in which the conse- 
quences of systems failure are very serious. Although many approaches have 
been proposed to construct high-confidence embedded systems, most of them 
are proposed for the development of monolithic embedded systems. Building 
high-confidence SoES is still a great challenge. Eurther efforts on studying 
novel technologies for the development of SoES are needed. In this paper, we 
present a computational model which serves as a basis to construct prototype of 
SoES. 



1 Introduction 

Requirements for individual embedded systems working together towards broad, 
common objectives have been receiving greatly increased amounts of attention be- 
cause of large investments in existing isolated embedded systems. Systems of embed- 
ded systems (SoES) should be distinguished from large and complex but monolithic 
embedded systems by the independence of their components, their evolutionary na- 
ture, emergent behaviors, and a geographic distribution [1]. Furthermore, high confi- 
dence is critical for SoES since it has been widely used in many fields, such as flight 
control and avionics, process control, weapon system control and nuclear plant con- 
trol, in which the consequences of failure are very serious. 

High confidence is a perception of how a system should behave. It can only be es- 
tablished by measurable or certifiable attributes. Some relevant attributes of interest 
for high-confidence embedded systems are functional correctness, timely response, 
reliability, safety, security, robustness, testability and maintainability etc. 

Constructing high-confidence systems of embedded systems is a great challenge. 
This is because the individual component systems are independently developed and 
therefore typically run on different platforms and have different data formats and 
interaction protocols. Novel technologies to construct high-confidence SoES are 
needed to overcome these challenges in an effective and sound way. At the same 
time, accurately describing requirements is the most important step in the develop- 
ment of SoES since requirements specification serves as a basis and start point for all 
further development activities such as prototyping, verification, and code generation 
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etc. Thus, in this paper, we present a computational model for SoES to capture the 
functional and non-functional aspects of requirements for SoES. 

The rest of the paper is organized as follows: section 2 introduces some related 
works; section 3 presents the computational model for SoES; section 4 is conclusion 
and future work. 



2 Related Works 

In recent years, many approaches have been proposed to construct high-confidence 
embedded systems. Those approaches include verification, run-time testing and moni- 
toring, and component-based composition. 

[2], [3], [4] and [5] are some typical research works for the approach based on veri- 
fication. These works use model checking to verify the satisfaction of some properties 
such as survivability properties. [2] uses a model checker based on NuSMV to verify 
the survivability properties in embedded systems. [3] focuses on the specification and 
analysis of publish-subscribe software architecture. It specifies the properties in linear 
temporal logic and uses the SMV model checker to complete the verification. [4] 
gives an efficient procedure for verifying that a finite-state concurrent system meets a 
specification expressed in a (propositional, branching-time) temporal logic. In [5], the 
requirements are formalized in temporal logic and the system model is abstracted 
from the source codes so that some real-time properties are verified. [6] focuses on 
the verification of real-time systems. It presents a modular framework for providing 
temporal properties of real-time systems basing on clocked transition systems and 
liner temporal logic. In this framework, the properties of real-time systems can be 
established by use of deductive verification rules, verification diagrams and automatic 
invariant generation. 

For run-time testing, both [7] and [8] attempt to automatically generate the test 
suite from the formal requirement specification. Furthermore, [7] uses model check- 
ing while [8] uses a test derivation schema to achieve this purpose. [9] presents a 
comprehensive method for run-time monitoring. It uses a monitor script to generate a 
filter and event recognizer and generates a run-time checker basing on a formal speci- 
fication so that a set of resource-specific, safety and real-time properties are moni- 
tored and checked at run-time. 

For research on component-based composition, [10] presents a method for auto- 
matic integration of reusable embedded systems. This research uses a component 
model, a component behavior model and a control plan to compose reusable compo- 
nents in embedded systems. Timing constraints and resource constraints are consid- 
ered during the component composition. 

However, most research focuses on development methods for building high- 
confidence monolithic embedded systems rather than the high-confidence SoES. 
Further efforts on studying novel technologies for high-confidence SoES development 
are still needed. Moreover, development of large software systems causes a sequence 
of modeling tasks. It requires the modeling and description of the application domain, 
software requirements, software architecture, software components, programs, their 
internal structure and their implementation be it by one or by several modeling con- 
cepts [1 1]. In this paper, we present a computational model which serves as a basis for 
development of high-confidence SoES. 




263 Luqi, Ying Qiao, and Lin Zhang 



Furthermore, many approaches assume the existence of an accurate and valid for- 
mal specification of the properties that are to hold with high confidence. The last 
thirty years of computing research have shown that this assumption does not hold in 
practice, and that a majority of software faults can be attributed to requirements and 
specification errors. Prototyping has emerged as a preferred method for requirements 
validation. We therefore explore support for prototyping of SoES as a complement to 
approaches for certification. The main purpose of this work is to ensure that the speci- 
fied properties, to be certified by other methods, are valid with respect to the real- 
world context of the SoES and the real-world needs of its stakeholders. 



3 Computational Model for SoES 

Computational model is a mathematical model that describes requirements of SoES. It 
has two views: external view and internal view. The external view model describes 
requirements from user’s view while the internal view model is more close to the 
design’s view. 



3.1 External View Model 

External view model describes the requirements via functional and non-functional 
emergent properties. In this context, emergent properties refer to the properties of 
entire SoES that do not reside in any individual embedded system. They describe 
additional requirements to be met by the integration of the component systems. They 
represent the value added by the interaction, and are typically not satisfied when the 
component systems are all operated as isolated systems. 

Eormally, the external view computational model can be represented as follows: 

C = (G , // ) (1) 

G is a functional emergent property vector which represents the functional require- 
ments of SoES, G = {g g 2 , g i) ■ giii denotes one of functional 

emergent properties of SoES. I is the number of functional emergent properties. The 
most typical functional emergent properties identified in external view model are 
timing properties such as maximum response time (MRT). 

H denotes non-functional emergent properties, i.e., high-confidence properties 
that reveal the non-functional requirements of SoES. Since high confidence can only 
be established by measurable attributes, these non-functional emergent properties 
need some practical metrics that can be automatically measured by a repeatable proc- 
ess. Thus, we use a high-confidence metric vector to describe high-confidence proper- 
ties. In this context, H = , where [1, z] ) is the set of metrics for 

a measure of high confidence. The entries of the sets are monotonically increasing 
real functions, where larger metrics values denote better confidence. 

There are several widely accepted measures related to different aspects of high 
confidence, such as availability, reliability, safety, security, maintainability and integ- 
rity, etc. Eurthermore, there are one or more than one corresponding metrics for each 
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measure. Some typical metrics are failure rate, maximum time between two succes- 
sive failures, the number of faults that can be tolerated, maximum time between safety 
violations and security level etc. The required confidence level with respect to the 
specified application field can be represented by a vector of threshold values 

W = [Wj, W2C ■ ■ 5 ff’j,] . The vector represents the following high confidence goal, 
i.e., for all i G [1, z] , h. > W- . 

G and H reflect the functional and non-functional aspects of requirements for 
whole SoES. G can be used for (a) generating code for monitoring failure events 

during the reliability assessment and testing and (b) verification. H can be used for 
(a) experimental assessment of high-confidence attributes and (b) possible static veri- 
fication for some metrics, such as Maximum Execution Time (MET). 

3.2 Internal View Model 

Internal view model describes requirements of SoES via four elements, i.e., compo- 
nent systems, interactions between component systems, local constraints imposed on 
component systems and interactions between them. It is formally described bellow: 

C = (5 , £ , C , D , Fj, F 2 ) (2) 

S is the component system set, S={s,\iG [l,n]}. S- denotes the component sys- 
tem constituting SoES (n is the number of component systems in the whole SoES); 
E denotes the interaction sets between component systems, 

E = {e j!^ \ i ,k ^ \X,n \ } , where denotes the set of interactions from component 

system j to component system is a set of F jk elements. When Fyit — 1 > 

S jk \ y^ [I5 r jk \ } ; it means that there is more than one interaction from Sj to 

5^ . When Y jk — 0 > ^jk is empty; this means that there is no interaction from Sj to 

h- 

C denotes constraint sets on how the component systems are used in the given en- 
vironment, C = {C; I / G [1, n] } . C; is a set of constraints withp, elements. 

When/* > l,c, = {cf I . cf denotes the p"* constraint for S^. When 

Pi = 0 , Cj is empty; it means that there is no constraint on . D denotes constraint 
sets on interactions between component systems, D = {d \ j , k G [1, n]} , 
where djf, is a set of constraints with Qjj^ elements each of which applies to interac- 
tions in ejk . When Q j,, ^ 1 , d ^ G [1, 2 denotes the q® con- 

straint for e jj, . When Q = Q , it means that there is no constraint on e . 
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Constraint sets C and D are determined by functional and non-functional emer- 
gent properties in external view model, and C — F i(G , H ); D — Fi{G,H), 
where F i and F 2 are two mappings that map emergent properties of SoES into local 
constraint sets imposed on component systems and interactions between component 
systems respectively. 

In fact, and e describe the static structures of SoES while and describe 

the dynamic behavior of systems of embedded systems. The mappings specify what 
must be assessed to ensure that the SoES satisfies its requirement with high confi- 
dence, if it has already been certified that the individual s i meet their requirements 
with high confidence. The constraint sets also represent a design for the systems inte- 
gration, which will be realized by wrappers around the Si ■ 

3.2.1 Component Systems 

Component systems are a set of independent complex embedded systems. Each of 
them can fulfill its purpose if disassembled from the overall system, and can be man- 
aged (at least in part) for their own purpose rather than the purpose of the whole. As a 
matter of fact, a component system is a slot rather than a single fixed subsystem. The 
slot can be filled by any subsystem that meets the constraints specified at the level 
above. The analysis that leads to the assurance of high confidence should depend only 
on the constraints associated with the slots. In this way, if we have a set of concrete 
subsystems for each slot that have been certified to meet the constraints associated 
with that slot, then we can reconfigure SoES by plugging in different certified subsys- 
tems into corresponding slots without need for further recertification for each recon- 
figuration. Such a structure is needed to support rapid and low cost evolution without 
compromising high confidence. 

Each component system is either atomic or composite. Composite component sys- 
tems can be described by a hierarchical SoES computational model, i.e., it can be 
realized by interaction-link networks of lower level component systems while atomic 
component system can not be decomposed in terms of the SoES computational model. 

In order to represent the hierarchical structure of the composite component system, 
we introduce the layer for each component system. Each composite component sys- 
tem in a higher layer is composed of several sub-component systems in the next 
lower layer. In this case, the whole system of embedded systems is in the root layer 
which is the highest layer. Component systems that constitute SoES belong to the 
layer 1 which is just below the root layer. 

Eor any component system in layer 9 (9 > 0) , we can also describe it from ex- 

ternal view and internal view. Thus, we use Si and 5 , to respectively denote the 
external and internal view model of the component system. 

In the external view model, the hierarchical structure of the composite component 
system can be formally represented as follows: 

sf = (Gf,H^) 



(3) 
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0 

Oi denotes the functional emergent property vector for component system in layer 
a while H i represents the non-functional emergent property vector relevant to high 
confidence for component system in layer a . Gi and Hi are decomposed from 
* and ' for component system in the higher layer 0 — \ . 

Furthermore, although emergent properties are bottom-up, it is still meaningful to 
decompose them in SoES. The decomposition of emergent properties can guide the 
designer to choose suitable component systems to build SoES that meets the require- 
ments. This provides a systematic way to construct SoES rather than arbitrarily choos- 
ing current component systems to compose SoES which is hard to satisfy the re- 
quirements. 

In the internal view model, 5 , is formally represented as follows: 



e 

Si 



/ ^6+\ j-T^+1 ^0+\ -w^6+\ 

— \Oi ^ Ei 9 C / ^ Ui ^ r i,[ f r i,2 } 



( 4 ) 



denotes the component system set in the lower layer 0 -b 1 that constitutes sf > 
and S^i^^ — ^ [I 5 is the number of sub-component systems in 



lower layer 9 + 1-, is the t-th sub-component system in lower layer 9 + 1 which 
constitutes yf . represents the interaction sets in lower layer 9 + 1, and 

— ie^^kl j ■’k ^ [I 5 nf^*] } • denotes the interaction set between the sub- 
component system and the sub-component system in lower layer 9 + 1', it 
is a set of Tfjl elements, where Pfjit — 0 . 



denotes the constraint sets on sub-component systems in lower layer 9 + 1, 
and = [hnf^*]} ■ Eurthermore, cf^^is a set of constraints 

with p elements, where denotes constraint sets on interactions 

between sub-component systems in layer 9 + 1, 

andpif"^' = \ j,k+: [ 1 , , where is a set of constraints with Qi^jk 



elements each of which applies to interactions in Cijk . 

Eurthermore, as constraints on sub-component systems and interaction between 
sub-component systems in the lower layer can be derived from the decomposition of 
constraints in the higher layer, the relationship between constraints in two successive 
layers can be formally revealed by following equation: 



cr = m ) ; or = 



( 5 ) 
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where 77 ^ 2 * are two mappings that map the constraint sets on components 

system set Si and interaction sets Ei in layer Q into constraint sets on components 
system set 5 and interaction sets eT^^ in lower layer 9 + 1 respectively. 

Figure 1 is an example of a composite component system. In this figure, $i is a 
composite component system in layer 9. $i can be further decomposed into three 
sub-component systems layer. Moreover, efn and 

denote the interactions between these three sub-components in layer 9 + 1 . 




Fig. 1. Composite Component System 



Moreover, both composite component systems and atomic component systems are 
composed of an operator and a wrapper. The component system in layer 9 , i.e., 5 , , 
can be represented as follows: 



e 






( 6 ) 



0 0 

Where at denotes the operator; /, denotes a wrapper around component system 
e 

Si ■ 

The operator is the main part of a component system. It is either a functional ab- 
straction or a state machine abstraction and encapsulates a thread of control. Further- 
more, it is either timing triggered or event triggered. If the operator is timing trig- 
gered, the component system is triggered at fixed time instants and at approximately 
regular time intervals. However, if the operator is event triggered, the component 
system is triggered by the arrival of new interaction information such as a new data 
value, the occurrence of certain events etc. 

Wrapper is a software layer around the component system. It has two functions: (a) 
providing the service interface to other component systems, and (b) intercepting all 
service calls from other component systems. The wrapper can solve the interface 
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mismatch between the heterogeneous component systems and provide the error con- 
tainment and isolation, i.e., protect the wrapped component system from erroneous 
interacting component systems and also protect error propagation from the wrapped 
component systems to the outside world. 

3.2.2 Interactions between Component Systems 

Interaction sets E is composed of several interaction sets. For two specific compo- 
nent systems s j and Sk > there is an interaction set e jk ■ Each element in this interac- 
tion set, denoted by ejj. (/£ . is one interaction between component system 

S j and 5 ^. . It is formally represented as follows: 

Where, INT is an interaction operator; y represents the interaction information 

C- jk 

involved in the interaction between component system y j and y j. . 

The interaction information has two types - data stream and event stream. A data 
stream is used to connect two or more component systems. It is widely used in the 
typical producer-consumer architecture. Each data stream carries a sequence of data 
values. It has the pipeline property: Assume Com-1 and Com-2 are two component 
systems. If a and b are two data values in data stream Y and the data value a is gener- 
ated by Com-1 before the data value b is generated then it is impossible for a to be 
delivered to Com-2 after b is delivered. Furthermore, there are two types of data 
streams - data flow streams and sampled streams. The data flow stream guarantees 
that none of the data values is lost or replicated while a sampled stream does not make 
such a guarantee [12]. A data flow stream can be thought of as a FIFO queue, while a 
sampled stream can be thought of as a cell capable of containing just one value, which 
is updated whenever the producer or publisher generates a new value. Since embed- 
ded systems must often operate within a (small) bounded memory, the finite queue 
length imposes a restriction on the relative execution rates of two component systems 
communicating via data flow stream. However, a sampled stream imposes no such 
constraint, since it can deliver a value more than once if the consumer demands more 
values before the producer has provided a new value, and it can discard the previous 
value if the producer provides a new value before the consumer has used the previous 
one. 

For example, suppose the component system Com-1 produces a sequence of data 
values dj, d^_j, d^ in data stream Y, and component systems Com-2 will consume 
it. A queued sequence for Y is shown below. 

d nd w— 1 * • ‘d 2d 1 

If T is a data flow stream then Com-1 consumes all of the data values in data 
stream Y in the order d,, d^, . . ., d^_,, d^. If Com-1 produces data values in data stream Y 
faster than Com-2 consumes them, the length of the queued sequence increases until 
an overflow occurs. If Com-2 consumes data values faster than Com-1 produces 
them, Com-2 has to wait until the queued sequence becomes nonempty. This implies 
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that with a data flow stream, Com-2 may not meet its real-time constraints unless its 
data rate closely matches that of Com-1. 

If y is a sampled stream instead, the data rates do not have to match. For example, 
consider the case where Com-1 produces one data value in data stream Y every 2 ms, 
Com-2 consumes one data value every 3 ms, and a size one buffer is used for contain- 
ing the data values. Thus, since the buffer contains only one data value at a given 
time, the sequences of data values in sampled stream V consumed by Com-2 starting 
at different initial times can be different. In this case, Com-2 consumes the values d^, 
dj, d^, d^, ... with an initial time 2 and dj, d^, d^, d^, ... with initial time 1 . 

In SoES, individual embedded systems have high autonomy and they are tempo- 
rally combined together to archive a broad and common objective. It is often hard to 
confirm which component systems will be involved in the interaction in advance. 
Thus, the dynamic interaction is popular in SoES. However, data streams only can 
support static interaction. Since events are used to support publish/subscribe architec- 
tures, we introduce event streams in this computational model to support the dynamic 
interaction in SoES. Event streams are extensions of data streams that have additional 
operation for dynamic addition and removal of producer actions and consumer ac- 
tions. 

Each event stream is used to connect component systems that generate events to 
component systems that respond to events. The producers and consumers of an event 
stream can be added or removed during system execution. However, to ensure de- 
pendability of a system, a producer or consumer can be added to an event stream only 
if it has been pre-certified to meet the constraints associated with the interaction. 
During the interaction, the component system generating events is taken as the source 
of the interaction while component systems responding to these events are the 
destination of the interaction. Like data streams, event streams also have pipeline 
property. It is impossible that the destination component system responds to an event 
which is generated later before it responds to an event which is generated earlier. 

There are two types of event streams - event flow streams and sampled event 
streams. These are special cases of the data flow streams and sampled streams de- 
scribed earlier. 

3.2.3 Constraints on Component Systems and Interactions 

In this computational model, constraints on component systems and interactions be- 
tween component systems are divided into two categories, i.e., the constraints for the 
real-time features and the constraints for high-confidence features. 

• Constraints for Real-Time Features 

In the computational model supported by Prototype System Description Languages 
(PSDL)[12], a lot of work has been done for timing constraints and control constraints 
for real-time embedded systems. Although these two constraints were originally pro- 
posed for individual embedded systems, it is easy to extend them for the case of 
SoES. 

In the case of control constraints for SoES, whether the operator is PERIODIC or 
SPORADIC, triggering methods, triggering conditions, and output guards are the 
major aspects to be specified. This computational model supports both periodic and 
sporadic component systems. Periodic component systems are triggered at the regular 
time interval while the sporadic component systems are triggered by the arrival of 
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new data values or the occurrence of certain events, possibly at irregular time inter- 
vals. For the trigger method, this computational model can support data trigger and 
event trigger. Both data trigger and event trigger have two types, i.e., triggered by 
ALL and triggered by SOME. In the case of triggered by ALL, the corresponding func- 
tion of component system is ready to be activated whenever the new data values have 
arrived on all of the input data streams or the new event instances occur in all the 
input event streams. In the case of triggered by SOME, the corresponding function of 
component system is ready to be activated whenever any of the input streams gets 
new data value or the new event instance occurs in any one of the input event streams. 

Furthermore, by extending the conditionals in the computational model supported 
by PSDL to the case of SoES, the trigger conditions and the output guards can be 
derived in this computational model. The trigger condition serves as a guard for the 
correspondent function of component system. Thus, only when arrival data in the 
input data stream or occurring event in the input event stream satisfies the trigger 
condition, the correspondent function of the component system can execute. The 
output guards act as the condition for the output of component systems, i.e., only 
when the generated data or the event satisfies certain conditions, they can be put in 
the output data stream or event stream of component system. 

Timing constraints are critical for SoES. In this case, we can make use of the tim- 
ing constraints specified in the computational model supported by PSDL [12]. Maxi- 
mum Execution Time is one of the typical timing constraints for SoES. It can be im- 
posed on the component system. It represents the upper bound on the length of time 
between the instant when a module in the component system begins execution and the 
instant when it completes. Eurthermore, for the periodic component system, the tim- 
ing constraints include Period and Einish Within. Period is the interval between con- 
secutive trigger events while Finish Within is the upper bound between each trigger- 
ing event and the completion of the activation. Eor the sporadic component system, 
the timing constraints include Maximum Response Time and the Minimum Calling 
Period. Maximum Response Time is an upper bound on the time between the arrival 
of a new data value or occurrence of a new event instance and the time when the last 
value or the state change is put into the output streams of the component systems in 
response to the arrival of new data value or the occurrence of new event instance. 
Minimum Calling Period is a constraint on the environment of a sporadic component 
system, consisting of a lower bound on the delay between the arrival of one set of 
inputs and the arrival of the next set. In this computational model, every sporadic 
component system with a maximum response time constraint must have a correspond- 
ing minimum calling period constraint. 

In addition, we use Latency as the timing constraint imposed on the interactions be- 
tween component systems. The Latency of an interaction is an upper bound on the 
time between the instant a data value is written into a data stream or an event is gen- 
erated in an event stream and the instant that data value can be read from the stream 
or the event can be received from the event stream. 

• Constraints for High-Confidence Features 

To construct the high-confidence SoES, some constraints for high-confidence features 
that have not been previously included in the computational model supported by 
PSDL should be discussed. 

In this computational model, constraints for high-confidence features are derived in 
the high-level of internal view model by mapping emergent properties represented in 
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external view model. Consequently, these high-level constraints can be further refined 
into lower level constraints. 

Since Reliability is one of the most typical emergent properties related to high con- 
fidence, we take it as the start point to discuss constraints for high-confidence features 
in SoES. [13] attempts to refine Reliability into some constraints of fault tolerance. In 
this paper, we exploit this result to map reliability into the constraints imposed on 
component systems and interactions between component systems. 

Reliability refers to the property of continuity of correct service. It is the probabil- 
ity that no failure occurs in the time period [0, t]. Reliability, denoted by R (t), is rep- 
resented by following equation [14]: 

R{t) = ( 8 ) 



where A, denotes the failure rate. 

According to above equation, reliability can be quantified into failure rate. Based 
on this, we can analyze which design parameter will impact the value of failure rate 
so as to find out constraints related to high confidence. 

The failure rate refers to the number of failures in the unit time. As we know, fault 
tolerance is an important way to reduce the failure rate in SoES. This provides a po- 
tential way to map the failure rate into some concrete constraints of fault tolerance 
mechanism in the high-level internal view model. 

Reliability states that, each faulty state in the execution trace of the system is fol- 
lowed by a state which is a superset of some states in the trace of the correct execu- 
tion of some equivalent system, i.e., even if failure products are not removed, the 
behavior expected by a correct system execution will still be observed. Since masking 
of failures is a well-known fault tolerance abstraction and expresses the fact that a 
failure event is not perceived by some part of the failed system’s surrounding envi- 
ronment, it captures the fact that a faulty state is followed by a state which is a super- 
set of some states in the trace of the correct execution of the same system. Therefore, 
in the high-level internal view model, failure rate can be refined into the constraint of 
masking which indicates the basic style for the fault tolerance. 

To strengthen the masking, one way is to combine the constraints of DetectionObj 
and MaskObj. In here, the former constraint expresses the fact that there exists a com- 
ponent system which sends a message containing a notification about the failure event 
in the case of a failure. The latter constraint expresses the fact that the failure of a 
given component system can be masked by an component system with equivalent 
specification, which has performed until the failure event an execution equivalent to 
the one of the failed component system, and it continues its execution after the point 
of the first component system’s failure. 

Another way to strengthen the masking is to combine the constraints of Diffuse and 
Active. Diffuse constraint expresses the fact that a message sent to a member of a 
multicasting group will be eventually received by all members of that group. Active 
constraint expresses the semantics of the replication scheme. Thus, in the lower level 
of internal view model, masking can be further refined into four constraints that are 
DetectionObj, MaskingObj, Diffuse and Active. 
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4 Conclusions and Future Work 

High confidence is important for embedded systems that are usually used in the fields 
where system failures will result in serious consequences. Systems of embedded sys- 
tems have been used widely in recent years due to requirements for combining the 
individual embedded systems to accomplish the broad and common objectives. Typi- 
cal examples of SoES include National Aviation Systems (planes, airports, airways, 
air traffic control), Naval Mine Countermeasures Force systems (search, sweep, neu- 
tralization systems). Naval Surface Fire Support systems (reconnaissance, targeting, 
weapon systems), and Theater Ballistic Missile Defense systems (surveillance, track- 
ing, interceptor systems). 

At present, several approaches have been presented to construct high-confidence 
embedded systems. These approaches include formal verification based on model 
checking, run-time testing and monitoring based on formal specification and the com- 
ponent-based composition based on behavior verification analysis from integrated 
behavior model and component behavior model. However, all these approaches were 
proposed for the monolithic embedded systems. It is necessary to make further efforts 
on constructing high-confidence systems of embedded systems. Thus, in this paper, 
we present a computational model which serves as a basis and start point for the de- 
velopment of high-confidence SoES. 

Further research should be carried out to support practical application of the pro- 
posed model. In addition, methods for mapping other high-confidence emergent prop- 
erties such as availability and safety into constraints imposed on component systems 
and interaction need to be further studied and more constraints related to high- 
confidence attributes should be developed. 
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Abstract. Despite the existence of a seemingly continuous stream of 
new technologies and methods, software productivity remains univer- 
sally unimpressive. We argue that, as long as industry remains focused 
on short-term goals, and maintains a technology-centric view of soft- 
ware development, no progress will be made. A clear symptom of this 
problem is the fact that the metaphors we apply to software develop- 
ment are largely obsolete. Instead of thinking about software as we do 
about bridges, buildings or hardware components, we should encourage 
a view of software as a living and evolving entity that is developed and 
maintained by people. We begin with some assertions that are intended 
as food for thought. We continue by reviewing what we consider to be 
some of the key difficulties with software development today. We con- 
clude with a few recommendations for research into software practices 
that take evolution into account. 



1 Food for Thought ... 

~ Software “engineering” is only a metaphor. 

— Software “architecture” is only a metaphor. 

— Software “components” are only a metaphor. 

— The most cost-intensive phase of any successful software project is “mainte- 
nance” . 

— What is termed “maintenance” consists in practice of continuous develop- 
ment and software evolution. 

— Poor software quality is the greatest impediment to software evolution. 

— Formal methods have a strictly limited impact on software quality in general. 

— Constant refactoring is a prerequisite for effective software evolution. 

— Aggressive testing is a prerequisite for refactoring. 

~ Standardized architectures and interfaces are a prerequisite to effective com- 
ponent reuse. 

— A good software architect must be a good abstract thinker. 

— Comparatively few programmers are good abstract thinkers. 

— Software reuse can only have a limited impact on a small portion of the 
software lifecycle. 

— Software reuse does not come for free. 

~ Object-oriented programming offers a means to model complex domains. 



Wirsing et al. (Eds.): RISSEF 2002, LNCS 2941, pp. 274-282, 2004. 
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— It is hard to develop models that can be easily adapted over time. 

— Objects are not components. 

— Object-oriented designs expose a class hierarchy, not a run-time architecture. 

— Raising the level of abstraction is the only way to produce more in the same 
amount of time. 

— Scripting languages are the most effective rapid application development 
tools known today. 

— Scripting languages are good for “programming in the small” , not “program- 
ming in the large” . 

— Yesterday’s large programs are today’s small programs. 

— Different people are motivated by very different things. 

— Hardly anybody is motivated by money above all else. 

— Technologists are often motivated by technology. 

— Technology has only minimal impact on the success of a software project. 

— Effective communication is the single greatest factor contributing to the 
success of software projects. 

— Short and frequent iterations are a prerequisite for effective communication. 
~ You can lead a horse to water but you can’t make it drink. 

2 Software Evolution and Productivity 

Despite the appearance of innumerable new software development techniques, 
tools and methods over the past couple of decades, there is a general percep- 
tion that software productivity has not actually improved as a result of these 
innovations. 

Why is this? 

First of all, let us consider what we mean by software productivity. From an 
Engineering perspective, we usually consider that productivity = units ^ effort 
[10]. Units of software can be notoriously difficult to measure, but, without 
belaboring the point, let us argue that 

. . functionality © quality 

productivity = 

enort 

where © is some kind of “addition” over functionality and quality. The desired 
functionality and quality are specified as Software Requirements, and the prod- 
uct is manifested in terms of Software Artefacts. Requirements being the input 
to our development process, productivity should just depend on the quality of 
the Requirements specifications, the methods and tools we use, and our own 
programming skill. 

At this point, however, we must not forget that “Software Engineering” is just 
a metaphor, in particular, one that says that “software is like a physical prod- 
uct”. Object-Oriented Programming, Component-Based Software Development 
(CBSD), and Software Architecture are other popular metaphors that suggest 
different ways of thinking about software. At the same time, however, metaphors 
can be dangerous if one forgets that they are just metaphors. 
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Fig. 1. Software evolution and productivity. 

Software Engineering itself may well be one of these dangerous metaphors. 
There are many ways in which software is not like a typical Engineering prod- 
uct. For example, software is not subject to physical constraints. Many software 
application domains are also highly unstable due to the high rate of innovation. 
The most striking of these differences, however, are perhaps those highlighted 
by the following laws of software evolution [13]: 

~ The Law of Continuing Change: A program that is used in a real-world 
environment must change, or become progressively less useful in that envi- 
ronment. 

— The Law of Lncreasing Complexity: As a program evolves, it becomes more 
complex, and extra resources are needed to preserve and simplify its struc- 
ture. 

This tells us that the Requirements are not the only input to our devel- 
opment process, but that legacy Artefacts also constitute an important input. 
Furthermore, as the Artefacts evolve. Requirements will also evolve in a never- 
ending cycle (see figure 1), and, as complexity increases, quality will degrade 
and productivity will decrease. 

Oddly, most software development methods seem to assume that a new ap- 
plication is being developed rather than that some existing software base is being 
extended or modified, whereas in practice the latter is almost always the case. 
Most of the real problems with software development, in fact, have to do with 
software evolution: How can we construct software systems that can be grace- 
fully adapted to changing requirements over time? If we consider most of the 
other perceived problems (poor quality, lack of reuse, and so on), they are largely 
subsumed by the problem of software evolution. 

If we consider the typical lifecycle of a successful software product, we quickly 
see that most of the costs are associated with its life after deployment [3,14]. 
Furthermore, what is often misnamed “maintenance” actually consists mainly of 
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addition of new functionality, z.e., continuous development, or simply software 
evolution [3,14] . This suggests that the impact of evolution of productivity cannot 
be merely incidental or occasional, but fundamental to software productivity. 
Attempts to improve productivity that do not take this into account are therefore 
doomed to failure! 

If software evolution is really the key issue in developing successful software 
systems, why is it almost universally ignored in proposals of new methods and 
techniques for software development? 

2.1 What’s Wrong with OOP? 

In the 1980s, object-oriented programming was widely considered to offer so- 
lutions to a wide range of software woes. In the 1990s, by the time that OOP 
became mainstream, it was clear that it was not a silver bullet. Worse, the 
learning curve with OOP is much steeper than with conventional procedural 
programming [15], reuse with OOP is much harder to achieve than with simple 
libraries of procedures, and all the problems with legacy applications recur with 
OOP except that they have an object-oriented flavour [9]. 

Implicit Architecture. Whereas procedural source code reflects procedural design 
quite well, object-oriented code does not normally reflect the run-time 00 ar- 
chitecture. That means that it is typically much harder to read and understand 
a well-designed object-oriented program than it is to understand a well-designed 
procedural one because the source code exposes a class hierarchy, not the set of 
objects that provide the run-time behaviour. In order to understand the run-time 
behaviour, one needs to know which objects will be instantiated and how they 
relate to one another. Due to polymorphism, however, this information can be 
very hard to extract. This steep learning curve can make it hard to understand 
and evolve an object-oriented application. 

Implicit Reuse Contracts. Although OOP offers very expressive mechanisms for 
software reuse, these mechanisms can be hard to understand and use correctly. 
An object-oriented framework consists of a class hierarchy that must be sub- 
classed and extended to instantiate an application. Frameworks make use of 
many common idioms and design patterns, and the rules for correctly subclass- 
ing the framework classes typically entail reuse contracts [20] that may only be 
implicit in the code. Not only are 00 frameworks hard to develop, but they 
entail a steep learning curve to use them. 

Missing Sockets and Plugs. 00 frameworks tend to be based on “white box 
reuse”, i.e., requiring knowledge of implementation details. Black box (com- 
ponent-based) reuse is more attractive since it makes the reuse contracts explicit 
as plugs (plug ’n play). Current 00 analysis and design methods, however, 
encourage designers and developers to model domain objects in a way that leads 
to rich interfaces that are not plug compatible. This means that OOA/OOD as 
it is practiced today conflicts with the principles of CBSD. 
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Refactoring. Although it is well-established that the quality of 00 software de- 
pends on a culture of refactoring and reengineering [9], it is still hardly standard 
practice. 

Although OOP has demonstrated some benefits for productivity through 
reuse of libraries and frameworks, object-oriented methods alone do not espe- 
cially address software evolution, so their impact on productivity is necessarily 
limited. 

2.2 Are Components the Solution? 

Although “object” is not yet a four-letter word, “component” seems to be the 
current buzz. But components, like objects, have also been around since the 
sixties [16]. 

Szyperski defines a software component as “a unit of independent deploy- 
ment, a unit of third-party composition, [that] has no persistent state” [21]. 
Clearly this definition can fit many different kinds of software entity. Whether 
we call it a “component” or a library or a framework or an application generator 
or a 4G environment or a programming language does not really matter. In each 
case, the key idea is to factor out everything that is known and stable and put 
it into a box, thereby raising the level of abstraction. In each case, components 
may be composed by means of a graphical or textual specification that plugs 
together compatible parts. 

The idea of building applications by “simply plugging together components” 
is very attractive, and certainly has some merit. But what is often forgotten is 
that components do not come from thin air. The cost of developing “reusable” 
components is significantly higher than that of building isolated applications 
[3,15] . Repositories of existing software elements help no more than do catalogues 
of the contents of junkyards (unless you are a junkyard artist). CBSD can only 
be successful when the process of developing components proceeds in parallel 
with the process of developing applications based on components, and the cost 
of developing components is amortized by the gains in productivity in developing 
and maintaining the resulting applications [11,17]. 

So what is the added value of CBSD? Certainly more rapid development is a 
gain in productivity since components will only have to be developed once. But 
the cost of developing and maintaining components can be higher than that of 
developing applications that are not component-based. Certainly higher software 
quality can be achieved by reusing components that have been thoroughly tested 
across a range of applications. But this presupposes a significant investment in 
ensuring the quality of the components, and presupposes a robust infrastruc- 
ture for composing them. Only such a compositional infrastructure can enable 
“independent deployment” . 

If the biggest cost in the lifecycle of applications is evolution, we should ask 
ourselves if CBSD can help reduce maintenance costs. A component-based appli- 
cation clearly separates what is stable from what is not. Increased productivity 
during software evolution means that new functionality can be more easily in- 
tegrated, and existing functionality can be more easily adapted. However this is 
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not achieved by components alone. We know and understand components, but 
what is hard to manage is flexibility. 

So, although CBSD addresses software evolution to a greater degree than 
does OOP, mainly by facilitating certain kinds of change, it fails to address the 
hardest problems. The metaphor of “component-based software development” 
puts the word “component” in the pole position, but this is misleading. The real 
added value comes from how components are composed, so perhaps we should 
start to think more about composition-based software development. 

2.3 What about Formal Methods? Testing? ... 

Software quality pays off during deployment and evolution. Correctness, reliabil- 
ity, efficiency, usability, maintainability, portability, and other software qualities 
have an impact either on the cost of deployment or the cost of development and 
evolution of a piece of software. Costs, on the other hand, are entailed while 
achieving and in maintaining that quality. When is it worth paying for that 
quality? Whenever a piece of software is expected to live beyond an iteration or 
two of its lifecycle, the investment in its quality can be amortized over its future 
lifetime. 

Formal methods clearly have their place in software development. However, 
many critical aspects of software quality are inherently impossible to formalize 
(for example, whether the user requirements have been adequately captured) [4] . 
Aside from certain well-understood domains, the cost of formally specifying re- 
quirements is not only exorbitant, but the cost of proving the correctness of 
an implementation may be unacceptably high. Furthermore, although there are 
some well-documented counter-examples [12], such as the application of model- 
checking tools, formal specifications and proofs typically do not scale well to large 
systems, and are rarely robust in the face of evolutionary changes. This suggests 
that formal methods most likely have their place in ensuring the robustness and 
correctness of individual, functional software components, but not necessarily 
assemblages of components, or non- functional aspects of software systems. 

Testing has the clear disadvantage that it can never be used to demonstrate 
the absence of software defects [7]. Despite its obvious shortcomings, however, 
aggressive testing during development and evolution can have a dramatic im- 
provement in software quality and software productivity [2]. Furthermore, tests, 
particularly automated unit tests, can be highly robust in the face of change. 
The investment in the development of test cases therefore rapidly pays itself 
off. Considering that software needs to be tested and debugged in any case, the 
investment in developing reusable test cases can be paid off even in a single it- 
eration of the software lifecycle. It is therefore astonishing that industry largely 
continues to consider it to be a completely separate activity from development, 
and many developers consider it to be an unnecessary luxury. 

There are innumerable other techniques and methods that may or may not 
have an impact on software productivity. Code reviews, coding standards, CASE 
tools, CRC cards, and so on, affect software quality in various ways, but each 
may or may not have a positive effect on productivity in the long run. We suggest 
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that any technique should be evaluated in the context of software evolution over 
a large number of iterations. A technique that is not cost-effective over time and 
robust in the face of changes cannot help software productivity in the long run, 
or can do so only in a very limited context. 

2.4 Peopleware and Agile Processes 

Methods, tools and processes all have their place, but it is important to recall 
that (i) productivity of software developers varies enormously, independently of 
tools or techniques applied, and (ii) the most important factor contributing to the 
success of a software project is typically the motivation of the team. Models and 
standards like CMM [18] and ISO 9000 [19], can be useful to assess the maturity 
of the process within an organization, but this need not bear any relation to the 
productivity of its development teams. Teams with immature processes may be 
highly productive, and organizations with mature processes may be moribund. 
Optimizing processes with negative and positive feedback are surely a Good 
Thing, but this is not necessarily the key to higher productivity. 

In the Silver Anniversary edition of The Psychology of Computer Program- 
ming, Weinberg notes: 

In the first edition to this book, I predicted, “... attention to the sub- 
ject of personality should make substantial contributions to increased 
programmer performance — whether that attention is paid by a psy- 
chological researcher, a manager, or the programmer himself” (p. 158). 
Even though I knew next to nothing about personality at the time, this 
turned out to be one of my most successful predictions. [22] 

Since that time, numerous authors have pointed out that technology has only 
a limited effect on software productivity [3,6,8,11]. Not only can there be a huge 
difference in productivity between individual developers (variously claimed to be 
10:1 or even 50:1), but factors such as team communication and motivation have 
repeatedly been shown to far outweigh any technological factor in the success 
of projects. Alistair Cockburn, for example, reflecting on 20 years of experience 
with various projects notes that: 

~ Almost any methodology can be made to work on some project. 

— Any methodology can manage to fail on some project. 

— Heavy processes can be successful. 

— Light processes are more often successful, and more importantly, the 
people on those projects credit the success to the lightness of the 
methodology. [5] 

DeMarco and Lister give many reasons for these phenomena in their book 
Peopleware, which can be summed up as: 

The major problems of our work are not so much technological as 
sociological in nature. [8] 
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If we can accept the idea that there can be no purely technological silver 
bullet [3], then we must conclude that our only hope is to pay more attention 
to sociological issues in the software process. The “Manifesto for Agile Software 
Development” adopts this point of view by proposing that we should value: 

Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 
Responding to change over following a plan [1] 

Although there appears to be no claim in this manifesto that agile processes 
will improve productivity in the long run, it is clear that, as a metaphor, agile 
software development gives change a central role, and downplays purely techno- 
logical tactics. This, we feel, is an important step in the right direction. 

3 Research 

We have argued that software evolution is the most important factor to influence 
productivity in any software development project. This leads us to the following 
observations: 

1. Software evolution is unavoidable, both before and after deployment. Ignor- 
ing its influence will kill productivity. 

2. Raising the level of abstraction is the only way to produce more in the same 
amount of time. 

3. Agile processes take into account that software is a living thing, whose life 
source comes from the interactions of the people who use it and develop it. 

We conclude that further research is urgently needed in the following areas: 

— Refactoring, reengineering and round-trip engineering, 

— Migrations towards component frameworks and software product lines, 

— Testing strategies to support continuous development, 

— Agile processes, 

— Composition languages and infrastructures, 

— Architecture-driven software development. 

Weinberg’s Psychology of Computer Programming was written over 30 years 
ago, but we have been slow to pick up on its lessons. Cockburn puts his case 
well: 

His characterizations and recommendations, based upon project in- 
terviews in the 1960’s, are still accurate and significant 30 years later. 
That validates the stability and importance of these sorts of issues. It 
is about time we studied these issues as a core to the field of Software 
Engineering and stopped rediscovering their importance every 30 years 
[5]. 
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Abstract. In recent times, there has been growing interest in model checking 
software systems. Such efforts bring into focus the memory constraints of 
model checking approaches. In this paper, we present our results from the 
analysis (at the source code level) of a real-time operating system using the 
Spin model checker and explain our efforts to understand the reasons for the ex- 
tremely large state space. Our studies indicate that even hand-optimized models 
suffer from memory constraints, thereby indicating the need for other ap- 
proaches that break the problem into smaller pieces. 



1 Introduction 

Model-checking is attractive for formal analysis of systems due to the automatic na- 
ture of their proof processes and also due to their ability to provide counter-examples. 
Model checking has long been used for verifying protocols and algorithms at an ab- 
stract level. Unfortunately, for many systems, the chief design artifact is the source 
code, and establishing the correctness of that source code is critical. In the past, veri- 
fication of source code had been considered impractical due to the extremely large 
memory requirements. Recently, with the availability of cheap memory and identifi- 
cation of various optimization techniques, there has been growing interest in verifying 
software systems at the source-code level ([5] and [13]). 

Under a cooperative research agreement with NASA’s Langley Research Center, 
Honeywell is developing and applying formal techniques to verify safety-critical 
properties in Integrated Modular Avionics (IMA) components such as the DeosT*^ 
real-time operating system. We believe that the use of formal techniques to increase 
avionics software design assurance will be crucial to aviation safety over the next 
decade. 

This work and the approach taken began with an earlier project undertaken with 
the Automated Software Engineering group at NASA Ames [11]. The model checker 
Spin [7] was used to model and verify portions of the original version of the Deos 
scheduler. The model was derived directly from the actual flight code so that the 
analysis results would be closely connected to the real system. 



This material is based upon work supported in part by NASA under cooperative agreement 
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Fig. 1. Decs components and terminology. 



Our current work focuses on the modeling and analysis of advanced features of the 
latest version of Deos, such as slack scheduling and aperiodic interrupt servicing. 
These new features add considerably to the complexity of the software. Our analyses 
indicate that, in spite of all the optimizations, the memory requirements are so great 
that exhaustive verification of even specific configurations of the system cannot be 
performed using 4GB of memory (the maximum amount of memory that can be used 
by Spin). 

This paper is organized as follows. In the next section, we present an overview of 
the DeosT*^ operating system and the features of the operating system that have been 
incorporated in our model. The sections following this present a brief overview of our 
modeling approach and the various optimizations incorporated in our model. In sec- 
tion 5, we present the configurations for which the results are provided in section 6. 
Following this, the current and future directions for our work are presented. The final 
section discusses the general context within which this particular work is being con- 
ducted. 



2 The Deos™ RTOS 

The Deos real-time operating system [1] was developed by Honeywell for use in the 
Primus Epic avionics suite for business, regional, and commuter jet aircraft. Deos 
hosts many safety-critical applications in these aircraft, including primary flight con- 
trols, autopilots, and displays. 

Deos is a microkernel-based real-time operating system that supports flexible Inte- 
grated Modular Avionics applications by providing both space partitioning at the 
process level and time partitioning at the thread level. Space partitioning ensures that 
no process can modify the memory of another process without authorization, while 
time partitioning ensures that a thread’s access to its CPU time budget cannot be im- 
paired by the actions of any other thread. 

The main components of a Deos-based system are illustrated in Figure 1 . A given 
software application consists of one or more processes. Each process is executed as 
one or more threads. All threads in a process share the same virtual address space in 
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memory. Each hardware platform in the system has a separate instance of the Deos 
kernel running on it. The kernel communicates with its underlying hardware via its 
hardware abstraction layer (HAL) and platform abstraction layer (PAL) interfaces. 
The HAL provides access to the CPU and its registers and is considered part of Deos 
itself. The PAL provides access to other platform hardware, such as I/O devices and 
interrupt signals. The application threads interact with the kernel and obtain the ser- 
vices it provides by means of a set of functions called the application program inter- 
face (API). 

Basic Scheduler Operation 

Deos must ensure that every application gets its allotted amount of CPU time every 
period. This provision is called time partitioning, and is accomplished by the Deos 
scheduler. At system startup, each process is given a fraction of the total available 
CPU resource, called the process’s CPU budget, for its use. The process then allocates 
its CPU budget to its threads. Deos ensures that each of the threads has access to its 
allocated CPU budget every period. 

There are three types of threads managed by Deos: the idle thread, the main 

thread, and user threads. The idle thread does nothing and has the lowest priority in 
the system. It is executed whenever there is nothing else for the scheduler to run. Each 
Deos process has a main thread that is automatically created at startup and manages 
resources allocated to the process. The main thread may create any number of user 
threads to perform the work to be done by the application process. Resources for user 
threads (such as their time budgets) are provided by the main thread. User threads 
may be static and created at system startup, or dynamically created at run time. Both 
main and user threads may delete themselves. The state diagram for running threads is 
shown in Figure 2. 

The Deos scheduler enforces time partitioning using a Rate Monotonic Scheduling 
(RMS) policy. RMS assigns thread priorities so that shorter period (high rate) threads 
are assigned a higher priority than long period (low rate) threads. Using this policy, 
threads run periodically at specified rates and they are given per-period CPU time 
budgets, which are constrained at thread creation so that the system cannot be over- 
utilized. 

Slack Recovery and Scheduling 

The restriction of applications to the use of a fixed CPU time budget in each period is 
often suboptimal. Many applications (for example, network service applications) have 
highly variable demands on the CPU and have a desired level of performance consid- 
erably greater than the minimum required. Giving these applications only the mini- 
mum budget necessary will result in low performance; giving them a high enough 
budget to ensure the performance desired will result in severe underutilization of the 
CPU most of the time and may “crowd out” other applications that users want to have 
in the system. 

For this reason, the Deos kernel provides a mechanism for “slack scheduling” 
which assigns system “slack” time to threads on a first-come first-served basis. The 
classical view of slack scheduling is given in [8]. The version implemented in Deos 
incorporates several major modifications of this view necessitated by the special fea- 
tures of Deos (e.g. the capability to dynamically activate and deactivate threads, and 
the existence of aperiodic threads). 
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Fig. 2. Thread state diagram with slack and interrupts. 



Servicing Aperiodic Interrupts 

Deos permits applications to respond to hardware interrupts via the activation of an 
interrupt service routine (ISR) thread. An ISR thread has a period and budget associ- 
ated with it, and like any other thread it is guaranteed access to its CPU budget in 
each of its periods. An ISR thread is activated by the arrival of its associated interrupt. 
Since the timing of the arrival of the interrupt can not be (in general) predicted, Deos 
does not guarantee that the ISR thread will complete in the same period that the inter- 
rupt arrived. This can happen, for example, if an interrupt arrives near the end of the 
thread’s period when the time remaining is less than the thread’s budget. 

To prevent an unbounded overloading of the system by bursts of an interrupt, an 
ISR thread has a period and a budget just like other periodic threads. Deos guarantees 
that the ISR will not consume more than its allocated CPU budget in each period, but 
Deos does not restrict the rate or number of interrupts that arrive so long as the ISR 
thread’s CPU budget is sufficient. System overhead (e.g., context switch time and 
cache effects) associated with preempting a running thread are all charged against the 
ISR thread’s budget. 

Overhead Accounting 

The basic Rate Monotonic Scheduling (RMS) theory used in Deos implicitly assumes 
that all of the time that the CPU executes is actually spent on user mode thread execu- 
tion; that is, it is assumed that context switches take zero time, and that there are no 
other system processing overheads that take time away from user thread execution. In 
the real world this is not the case. Deos performs a variety of scheduling and other 
activities that take time to execute. In order to preserve the assumptions of RMS, the 
time taken to perform any Deos kernel operation must be accounted for in one of two 
ways: 

1. By subtraction from the total CPU time available to executing threads. 

2. By charging the time to the budget of the thread running when the operation 



occurs. 
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When the kernel does work directly on behalf of a thread, the time is charged to 
that thread and deducted from its budget. Work that cannot be identified with a single 
thread (such as system tick interrupt handling) is deducted from the system timeline. 

Correctly accounting for overhead times for all of the functions that the scheduler 
must perform is critical to maintaining time partitioning guarantees. Kernel overhead 
time is broken down into a number of components. These times can vary for different 
hardware platforms. Platform integrators must determine upper bounds on these val- 
ues for their particular platform configurations. This can be done using an instru- 
mented version of the Deos kernel that provides data on the lengths of critical sections 
and the other overhead parameters. 



3 Project Requirements and Modeling Approach 

The key goal of this project is to verify that the time-partitioning property of Deos^M 
holds in the presence of its many features (such as slack reclamation and interrupts). 
In addition, the pre-conditions to many of the functions in the C-H- code (in the form 
of comments) must be verified to hold under all circumstances. Finally, automation of 
the translation is important. 

Several approaches were considered for this project. Symbolic model checking us- 
ing SMV[14] was rejected due to the large differences between the model structure 
and the source code structure. The approach for modeling sequential code in SMV is 
to model the code as a state transition system with a program-counter-like field to 
identify the enabled state (or line of source code) at any given time (for example, see 
[4]). This approach leads to very large model sizes and low correspondence between 
the model structure and the source code structure, thereby making the process of veri- 
fying model correctness difficult. Approaches based on Bounded Model Checking 
(BMC)[2] were rejected as they did not provide the necessary degree of correctness 
guarantee. Any conclusions drawn from the results hold only up to the depth specified 
during the verification. And increasing the verification depth to include the maximum 
model depth would result in BMC encountering the same memory problems as other 
verification techniques. Since the idea was to obtain as comprehensive a guarantee of 
correctness as possible, BMC-based approaches were rejected. The Spin-based ap- 
proach was selected due to the high degree of correspondence between the model and 
the source code, the support for assertions (which have lower memory requirements 
than use of temporal-logic properties) and its strong usage history. 

Our translation approach is based on the techniques developed by researchers at 
NASA Ames. The Deos kernel is written in an object-oriented style using C-H-. In 
contrast, Promela, the input language of the Spin model checker, is a process-based 
imperative style language that uses shared memory and message passing for commu- 
nication. In order to model objects within the framework of processes, and to make 
verification tractable, four basic techniques are used. 

■ Use data type abstractions for variables such as counters. Integers are modeled as 
bytes or even booleans, where possible. 

■ Model C-H- objects as arrays and object pointers as indices into the arrays. 

■ Convert methods into inline macros and replace recursion with distinct function 
calls. 

■ Flatten the inheritance hierarchy. 

The details of these translations are described in [1 1]. 
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The model consists of three parts - the kernel, user threads and the environment 
(see Figure 3). The kernel corresponds to the code translated from C++. It provides 
services to the user threads and interfaces with the hardware environment. It is the 
most complex part of the model. The user threads are very simple and just invoke 
various calls to the kernel and responds to messages (such as preemption) from the 
kernel. The environment provides the hardware services such as timers and interrupts. 
Though the environment is not as complex as the kernel, it is more difficult to model 
realistic hardware behavior in pure software. In our tests, we have found an event- 
based simulation-like approach to be the most suitable for modeling the environment. 




Automata to 
drive kernel 



Translated 
kernel code 



Fig. 3. Modeling Deos in Spin. 



4 Model Optimizations 

Model checking in general suffers from memory constraints. Therefore, appropriate 
optimizations are critical. Though the modeling was performed with automatic trans- 
lation in mind, the fact that it was hand translated enabled us to incorporate many 
optimizations in the model. Memory optimizations fall into two categories - those 
that reduce the size of the state vector, and those that reduce the total number of states 
in the system. 

Reducing the size of the state vector involved the replacing of all integer data 
types by the byte data type, and by actively tracking the variables that must be 
stored as part of the state. Promela has a hidden data type qualifier that excludes 
variables from the state vector. Judicious use of hidden variables results in models 
that make effective use of memory. 

The total number of states was reduced by the use of predicate abstractions. For 
example, it was noticed that the period counter variable was used to track whether 
individual threads had run at least once in the current period. By replacing the counter 
with a Boolean predicate, we were able to collapse states that differ only in the value 
of the period counter into a single state. 
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5 Configurations Analyzed 

Results are provided in the next section for the following selective models that have 
been verified correct using Spin. Each version represents an incremental improvement 
in the model or a bug fix from the previous version. A comparative table of the per- 
formance of each version with respect to several different parameters follows in Sec- 
tion 6. 

1. Baseline - no slack threads, no ISR thread'. This model consisted of our basic ver- 
sion with the latest changes to incorporate the overhead computations in the model. 
The model consists of the scheduler, the timer, a main thread, two user threads and 
the idle thread. None of the threads were slack consumers or ISRs. The overhead 
parameters were modeled at a high level of abstraction. An exhaustive search of 
the state space for assertion violations was performed for this configuration, with 
none found. 

2. No slack threads, no ISR thread, negative values for timer. During the analysis of 
the baseline model, we discovered that in the real system the time remaining on the 
timer can become negative, whereas we had modeled time as an unsigned byte. 
The remaining time of the various thread budgets can also be negative. This capa- 
bility was added to the model, and it was analyzed again. With this change, the 
number of states increased dramatically, making exhaustive verification impracti- 
cal. Therefore, we had to resort to bitspace (supertrace) verification [6] from this 
stage onwards. Typical coverage obtained using this technique was > 98%. 

3. Slack threads, no ISR thread, higher resolution for overhead variables'. Once we 
had a basic configuration working well, the next task was to add slack threads. 
When the user threads in the configuration were made slack consumers a number 
of assertion violations occurred. Understanding the reasons for the assertion viola- 
tions necessitated a better understanding of the relationships between the various 
system constants. Towards this end, the overhead variables were modeled at a 
higher degree of resolution. Each overhead variable was split into the constituent 
system constants as described in the Deos Design Document [1]. The longestCriti- 
calSection (LCS) was given a value of 1 . All other system constants were given a 
value of 0. 

4. Slack threads, no ISR thread, context switch time: Up to this point the time to per- 
form the context switch in hardware was assumed to be zero. In reality, context 
switches consume a finite amount of time. In order to reflect this fact, the time to 
perform a context switch was set to consume a non-zero amount of time (1 unit). 
Care was taken to maintain the ratios between the values of the various base sys- 
tem constants approximately consistent with realistic values encountered in the 
Deos Registry. Each time there is a change in the running thread, system time was 
advanced by the context switch time. 

5. Slack threads, one ISR thread, context switch time: Once the basic configuration 
was found to work well in the presence of slack consumers, aperiodic interrupts 
were introduced. This involved the designation of one of the threads as an ISR 
thread, and enabling the generation of interrupts by the environment. 
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6 Performance Results 

In this section, we first present an overview of the verification results for selected 
stages in the evolution of the current model, starting with the initial version to include 
overhead accounting. It can be easily seen from the results that the memory require- 
ments increase exponentially with addition of new features to the model. We then 
present an analysis of the results, intended to identify the reasons for the large in- 
crease in the memory requirements. 

In Table 1 we present the results obtained for each version of the model discussed 
in the previous section. E/S indicates the verification technique (Exhaustive or Super- 
trace) used. Except for the initial model where we used an exhaustive verification, all 
the other versions of the model were verified using Spin’s Supertrace verification 
technique [6]. The state vector size for all these models was 444 bytes. Depth repre- 
sents the longest single path from the initial state until a previously visited state is 
reached. States Stored represents the number of distinct states maintained by the veri- 
fier. Time is the total system time for the verification run to complete. Actual Memory 
is the total memory used by the application to store the state information. Equivalent 
Memory is Spin’s estimate of how much memory would be required to store all the 
states of the system if an exhaustive verification (with out any compression or optimi- 
zation) was used. 

With the addition of new scheduling features and overhead accounting the state 
space of our model has grown substantially. In addition, the longest traces found in 
the model (the reported depth) are far to long to examine manually. As a result, it has 
become necessary to introduce some approximations in the analysis and consider 
more carefully the structure of the model. 

Before adding the interrupts and overhead computations, the preferred method of 
analysis was by exhaustive verification in Spin. This technique keeps track of the 
complete state information for all the reached states while doing the analysis and 
gives the most accurate results regarding the correctness of the system. When success- 
ful, it provides 100% coverage of the state space. When it runs out of memory there 
are no guarantees about the correctness of the model. Given Spin’s current memory 
addressing limit of 4 GB (32 bits) and the size of the model’s state vector, it works 
very well for models with close to a million states. Once interrupts and overhead 
accounting were added to the model the state space quickly became too large to be 
analyzed by exhaustive verification. 

The alternative technique we had at our disposal was bit state or supertrace verifi- 
cation [6]. The Supertrace verification technique of Spin uses two independent hash- 
ing functions and stores only the results of the hashing functions for each state visited, 
marking the corresponding bits in a large table. If both hash functions yield a previ- 
ously marked bit then that state is considered to have been previously visited (a cy- 
cle). All the states (after the first) that result in such collisions are dropped from the 
analysis, and all subsequent states that could have been reached from the dropped 
states are not visited from the dropped state. This is less of a problem if the state 
space is highly connected as the unexplored states may be reached from other system 
states. 

The next issue was the coverage we were obtaining in the analysis. Spin gives an 
estimate of the coverage it obtained when using the Supertrace approach. Since an 
exhaustive search is not being performed, it is not possible to compute precise values 
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for coverage obtained. However, Spin has a mechanism to generate reasonably accu- 
rate approximation (called the hash factor) of the coverage that is based on the total 
memory available for the hash array and the number of distinct states stored in that 
array. The hash factor is directly proportional to the memory used by the hash array, 
and is inversely proportional to the number of states stored in the array. Until the 
addition of overhead computations we typically obtained estimated coverage (based 
on Hash Factor) of over 98%. Although it cannot be said with certainty that the sys- 
tem is bug-free based on 98% coverage, based our experience so far with the model, 
we believe that the probability of bugs being present is extremely low. 



Table 1. Performance results for verification of models in Section 5. 



Model 

# 


E/S 


Depth 
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Stored 

(e-l-06) 


Time 

(H:M:S) 


Actual 
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Memory (MB) 
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E 
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3.88 


57:26:37 
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338,155 
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95192.269 
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Fig. 4. Chart depicting the above results. 

With the addition of overhead computations, the estimated coverage obtained 
dropped to just above 90%. In our attempts to improve the hash factor (and thereby 
the coverage obtained), it seemed reasonable to increase the memory used by the hash 
array. Since the hash factor is directly proportional to the size of the hash array, in- 
creasing that should lead to higher values for the hash factor. But in reality we found 
that increasing the size of the hash array did not lead to a corresponding increase in 
the hash factor. This was because when the hash array increased in size the number of 
states stored by Spin increased proportionally, leading to the ratio being the same. Our 
conclusion was that the hash factor approximation for the coverage obtained works as 
expected only if the memory available for the hash array is sufficiently close (the 



292 Murali Rangarajan and Darren Cofer 



actual number of states is between one-half and one times the number of bits in the 
hash array) to the memory that would be needed to store all the states in the system. 

One interesting behavior of our model is that the depth (the longest sequence of 
states visited before a previously visited state is reached) is very high, especially with 
the later versions of the model. Though the complexity of the model could be a factor, 
it was not clear that the increased complexity alone could account for the very large 
increases in the depth. One possibility was that the depth was so high because of the 
sequential nature of all the different behaviors displayed by the model (see Figure 5). 
In order to validate the theory, we instrumented the model to simulate the behavior of 
Breadth-First Search. If the number of states reached by BFS were the same as that of 
the Depth-First Search technique employed by Spin, it would validate the hypothesis. 
We found that the number of states reached by using BFS was within 4.5% to 5% of 
the number of states reached by DFS. We believe that the difference in the number of 
states reached was due to the noise introduced by the instrumentation. Therefore, our 
hypothesis regarding the reason for the large depths appeared to be correct. 





All states 
reached with 
a depth of 10 



Fig. 5. Breadth-first vs. depth-first search of model. 



However, the operation of the supertrace verification mechanism casts some doubt 
on this conclusion. If the number of states stored is purely a function of the available 
memory for the hash array when the number of states is extremely large, then either 
DFS or BFS would give the same approximate value for the states stored. Therefore, 
in order to really answer the question, we need a model for which all the states can be 
stored in the hash array. To test this conclusion we reverted to a simpler version of the 
model. 

We performed exhaustive verification on a model without slack, interrupt threads 
or overhead accounting. We instrumented the model to perform a bounded depth-first 
search (BDFS), which was our approximation for breadth-first search. The bounds 
were set to coincide with the end of the longest periods. The results of our tests are 
shown in Table 2. The first column gives the number of longest periods that formed 
the bound for BDFS. It should not, in theory, have any effect on the results for DFS. 
In practice, however, we found a very slight decrease in the depth with increase in the 
number of longest periods in the bound. The reason for the decrease is not clear to us, 
but we believe that the decrease in depth is too small to have any effect on our con- 
clusions. The second column presents the results for DFS, and the third column for 
BDFS. For each search method the number of distinct states visited and the maximum 
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depth attained are listed. The results indicate that there is at least one longest path in 
the model whose states cannot be reached by performing BDFS. This implies that 
traversing the full depth of the model is necessary to visit all the states in the model, 
which puts our hypothesis in question. The original issue of why the depth should be 
so large has not been solved yet. 

We are continuing to look at other ways to obtain higher coverage. We have been 
working with Holzmann (developer of Spin) to increase the amount of memory that 
can be used in a supertrace verification. We have also been working on compiling 
Spin for a 64-bit architecture. (The current version assumes a 32-bit architecture, 
hence the 4GB memory limit). 



Table 2. Results in our analysis of DFS vs. BDFS. 



Max depth 
for BDFS 


Results using DFS 


Results usin 


gBDFS 


States 


depth 


states 


Depth 


1 


1.29524 e-^06 


38240 


1.04135 e-i-06 


7337 


2 


1.29524 e-^06 


38239 


1.04211 e-l-06 


10008 


19 


1.29524 e-^06 


38237 


1.26304 e-i-06 


28662 


29 


1.29524 e-^06 


38236 


1.29524 e-i-06 


38236 



7 Current Research 

Our main goal now is to identify new approaches to increasing the coverage obtained 
when using exhaustive verification. Simple approaches such as re-compiling Spin on 
a 64-bit architecture (thereby making more memory available to the process) are in 
reality not so simple. The core computations in Spin assume a 32-bit architecture, and 
changes to the core computations to reflect 64-bit architectures must be followed by 
an evaluation of the “correctness” of the tool. Since such an evaluation is difficult, the 
ideal solution must leave the core computations unchanged. Also, since we only use 
assertions to represent our correctness criteria, it is sufficient for our solution to ex- 
plore the state space and not handle LTL properties. Our leading contender for the 
solution is the use of secondary memory. 

The idea is to minimize the changes to the Spin code while enabling the use of 
more memory than is possible with 32-bit addressing. Towards this end, our solution 
is to run Spin as before, but at the point it runs out of memory, instead of reporting an 
error and exiting, to dump the set of partially explored and fully explored states on to 
secondary memory. The next run would take a partially explored state and proceed 
with the verification until all reachable states are explored or until it too runs out of 
memory. At this point, the states in memory are reconciled with the states stored pre- 
viously on the secondary memory. A new partially explored state is chosen next, and 
the verification run is repeated. The runs are repeated until there are no more partially 
explored states. The main drawback of this approach is the repeated exploration of 
states, since information about states explored in previous verification runs are “for- 
gotten” after it is stored on the secondary memory. We believe this loss can be offset 
by distributing the problem over multiple processes. 

We are currently using PSPIN [9] as the starting point for our work. PSPIN is a 
distributed implementation of Spin. It provides a wrapper around Spin that provides 
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the distributed functionality. PSPIN supports many different schemes for partitioning 
the state space among the various processors. Our studies with using PSPIN on a 
Deos model indicates that the partition functions are inadequate. In most cases, the 
load distribution was highly skewed, with some processors doing nothing while some 
processors doing a majority of the work. With Partial Order Reduction enabled, this 
skewed distribution resulted in some processors running PSPIN requiring more mem- 
ory than the single-processor Spin implementation, thereby defeating the whole pur- 
pose of distribution'. In the one case (Global Hash partitioning) where the memory 
was perfectly balanced between all the processors, the memory and time requirements 
were very high. We are in the process of identifying an appropriate hash function to 
achieve a good balance between processor memory load, and memory and time re- 
quirements. One of the techniques we are exploring is dynamic load balancing among 
the processors, while attempting to keep the overhead low. 



8 Conclusions and the Big Picture 

Model checking provides an attractive approach to formal analysis of complex sys- 
tems. But there are many hurdles in achieving the effective use of model checking for 
analyzing software. The most basic constraint is the scalability of the analysis tools. 
Memory constraints have always been a major impediment to the scalability of model 
checking tools. In this paper, we have described our efforts to alleviate this problem. 

The second issue concerns the kinds of software that can be model-checked. In the 
case of the Deos^M operating system, an arbitrary number of threads and processes 
may be active at any given time, with dynamic creation and deletion of threads and 
processes. It is impossible to verify all such configurations using only model check- 
ing. In general, a number of (provably correct) optimizations such as datatype abstrac- 
tions and predicate abstractions are used to restrict the model size. In the case of the 
Deos’'^ model, further restrictions on the number of threads and processes are also 
necessary. These restrictions on the model must be shown to not affect the validity of 
the model checking results. Therefore, it is necessary to prove that the restricted 
model displays the same behaviors (including buggy behaviors) as that of the unre- 
stricted model. Towards this end, we have created a simple model of the core Deos 
scheduler in PVS [12], a theorem prover capable of handling arbitrary number of 
threads, periods and processes. We are using this model in attempting to prove the 
validity of model checking results over just three threads, three periods and one proc- 
ess. 

The third issue is the actual creation of the model. The model must be created 
automatically for this approach to be of practical use, and we are in the process of 
writing a translator from C-H- to Promela to address this issue. One luxury available 
to programmers in C-H- that is not available to modelers in Promela is the use of tem- 
porary variables. Since C-H- supports true functions, programmers can declare tempo- 
rary variables as needed. When translating these temporary variables into Promela, 



' Partial Order Reduction (POR) has a large impact on the single-processor verification. Its 
effect decreases as the degree of parallelism increases. When determining the effectiveness 
of distributed implementations, it is important to enable POR in order to obtain meaningful 
results. 
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our initial approach was to declare them as hidden variables. We then realized that, 
since these hidden variables are not part of the state vector, this approach gave rise to 
unexpected and erroneous behavior from the verifier. But declaring all the different 
variables as local to a process or as global variables would result in a tremendous 
increase in the size of the state vector, thereby resulting in large increases to memory 
requirements. We are currently building a tool that would take in a translated Promela 
model with temporary variables declared as hidden variables, and would optimize the 
model to reuse a set of variables as much as possible. The tool would also insert 
atomic and d_step constructs appropriately so as to maximize the sections of the 
model that would be enclosed within these constructs. This optimization works for 
Deos because only one part of the model can be active at any given time. These two 
optimizations together are expected to reduce the memory requirements for the verifi- 
cation considerably. 

One final issue is the generation of an environment. The system being modeled 
may not work in isolation - it may provide services to other systems, or may request 
services from other systems. For example, Deos receives timing services (such as 
timers and periodic tick interrupts) from the underlying hardware, while it provides 
the operating system services to applications running on top of the operating system. 
Verification of the operating system requires accurate modeling of the environment 
behavior. Since the environment is not actually part of the system being verified, and 
since its behavior must be deduced from the expectations the system being modeled 
has regarding its environment, automated generation of the environment presents 
considerable challenges. As a starting point for solving this issue, we are considering 
means to generate stubs for the various functions that are called from within the oper- 
ating system. Also, since applications running on top of Deos trap into the kernel, we 
can generic applications that can trap into any kernel call without any restrictions. 
Then, based on the error traces, we can restrict the behavior of this generic environ- 
ment to enable only the valid behaviors. 
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Abstract. This paper discusses a model-based approach to software develop- 
ment. It argues that an approach using models as central development artifact 
needs to be added to the portfolio of software engineering techniques, to further 
increase efficiency and flexibility of the development as well as quality and re- 
usability of the results. Two major and strongly related techniques are identified 
and discussed: Test case modeling and an evolutionary approach to model 
transformation. 



1 Portfolio of Software Engineering Techniques 

Software has become a vital part of our lives. Embedded forms of software are part of 
almost any technical device from coffee machine to cars, the average household uses 
several computers, and the internet and telecommunication world has considerably 
changed our lives. All these machines are driven by a huge variety of software. Soft- 
ware that must never fail, must be updated dynamically, must continuously evolve to 
meet customers needs, must contain its own diagnosis and “healing” subsystems, etc. 
Software is used to for a variety of jobs, starting with the control of many kinds of 
processes up to simply to entertain. Software can be as small as a simple script or as 
complex as an entire operating or enterprise resource planning system. 

Nowadays, there is some evidence that there will not be a single notation or proc- 
ess that can cover the diversity of today’s development projects. Projects are too 
different in their application domain, size, need for reliability, time-to-market pres- 
sure, and the skills and demands of the project participants. Even the UML [1], which 
is regarded as a de-facto standard, is seen as a family of languages rather than a single 
notation and by far doesn’t cover all needs. This leads to an ongoing proliferation of 
methods, notations, principles, techniques and tools in the software engineering do- 
main. Some indicators of this ongoing diversity are: 

• New programming languages, such as Python [2] without strong typing systems, 
but powerful capabilities for string manipulation and dynamic adaptation of their 
own program structure compete with Java, C-H- and other conventional lan- 
guages. 

• The toolsets around XML-based standards [3] are widely and successfully used, 
even though they basically reinvent all compiler techniques known for 20 years. 
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• Methods like Extreme Programming [4] or Agile Software Development [5] dis- 
courage the long well known distinction between design and implementation ac- 
tivities and abandon all documentation activities in favor of rigorous test suites. 

• Upcoming CASE tools allow to generate increasing amounts of code from UML 
models, thus supporting the OMG’s initiative on “Model Driven Architecture” 
(MDA) [6]. MDA’s primary purpose is to decouple platform-independent models 
and from platform-specific, technical information. This should increase the reus- 
ability of both. 

• Completely new fields, like security, need new foundations embedded in practical 
tools. New logics and modeling techniques [7] are developed and for example 
used to verify protocols between mutually untrusted partners. 

Erom this observations it is evident that in the foreseeable future we will have a port- 
folio of software engineering techniques that enables developers and managers to 
select appropriate processes and tools for their projects. To be able for such a selec- 
tion developers need to be aware of this portfolio of software engineering techniques 
and master at least a comprehensible subset of these techniques. Today, however, it is 
not clear which elements the portfolio should have, how they relate, when they are 
applicable, and what their benefits and drawbacks are. The software and systems 
engineering community therefore must reconsider and extend its portfolio of software 
engineering techniques incorporating new ideas and concepts, but also try to scien- 
tifically assess the benefits and limits of new approaches. Eor example: 

• Lightweight projects that don’t produce requirement and design documentation 
need intensive communications and can hardly be split into independent sub- 
projects. Thus they don’t scale up to large projects. But where are the limits? A 
guess is, around 10 people, but there have been larger projects reportedly “suc- 
cessful” [23]. 

• Eormal methods have built a large body of knowledge, but how can this knowl- 
edge successfully and goal-oriented be applied in today’s projects? A guess seems 
to be, formal methods spread best, if embodied in practical tools, using practical 
and well known notations. 

• Product reliability need not be 100% for all developments and already in the first 
iteration. But how to predict reliability from project metrics and how to adapt the 
project to increase reliability and accuracy to the desired level while minimizing 
the project/product costs? 

• Promising techniques such as functional programming still need to find their 
place in practical software engineering, where they don’t play an appropriate role 
today. A guess is that e.g., functional programming will be combined with object- 
techniques such that functional parts can be embedded in conventional programs. 

Based on the observation for a general demand for a broad portfolio of SE tech- 
niques, we will in the following examine two trends that currently and in the foresee- 
able future will influence software engineering. These are on the one hand, the 
modeling notation UML and on the other hand agile development techniques. 
Although, these two trends currently work against each other, we can see that there is 
potential for their combination that takes benefits from both. 
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Section 2 discusses synergies and problems of using models for a variety of activi- 
ties, including programming. Section 3 explores the possibilities of increasing effi- 
ciency and reducing development process overhead that emerges from the use of 
models as code and test case descriptions. In Section 4 the overall scenario of a model 
based test approach is discussed. Section 5 finally presents the benefits of an evolu- 
tionary approach to modeling in combination with an intensive, model-based test 
approach. In particular, the usability of tests as invariant observations for model- 
transformations is explored. For sake of conceptual discussions, technical details are 
usually omitted, but can be found in [8]. 



2 Modeling Meets Programming 

UML [1] undoubtedly has become the most popular modeling language for software 
intensive systems used today. Models can be used for quite a variety of purposes. 
Among them are most common: 

• Informal sketches are used for communication. Such a sketch is usually drawn on 
paper and posted on a wall, but not even used for documentation. 

• More precisely defined and larger sets of diagrams are used for documentation of 
requirements and design. But requirements are usually captured in natural lan- 
guage and a few top-level and quite informal drawings that denote an abstract ar- 
chitecture, use cases or activity diagrams. 

• Architecture and designs are captured and documented with models. In practice, 
these models are used for code generation increasingly often. 

More sophisticated and therefore less widespread uses of models are analysis of cer- 
tain features (such as throughput, failure likelihood) or development of tests from 
models. Many UML-based tools today offer functionality to directly simulate models 
or generate at least parts of the code. As tool vendors work hard on continuous im- 
provement of this feature, this means a sublanguage of UML will become a high- 
level programming language and modeling at this level becomes identical to pro- 
gramming. This raises a number of interesting questions: 

• Is it critical for a modeling language to be also used as programming language? 
For example analysis and design models may become overloaded with details that 
are not of interest yet, because modelers are addicted to executability. 

• Is the UML expressive enough to describe systems completely or will it be ac- 
companied by conventional languages? How well are these integrated? 

• How will the toolset of the future look like and how will it overcome round trip 
engineering (i.e. mapping code and diagrams in both directions)? 

• What implications does an executable UML have on the development process? 

In [8,9] we have discussed these issues and have demonstrated, how the UML in 
combination with Java may be used as a high-level programming language. But, 
UML cannot only be used for modeling the application, but more importantly for 
modeling tests on various levels (class, integration, and system tests) as well. Execu- 
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table models are usually less abstract than design models, but they are more compact 
and abstract as the implementation. 

One advantage of using models for test case description is that application specific 
parts are modeled with UML-diagrams and technical issues, such as connection to 
frameworks, error handling, persistence, or communication are handled by the pa- 
rameterized code generator. This basically allows us to develop models independent 
of any technology or platform, as for example proposed in [10]. Only in the genera- 
tion process platform dependent elements are added. When the technology changes, 
we only need to update the generator, but the application defining models can directly 
be reused. This concept also directly supports the above mentioned MDA-Approach 
[6] of the OMG. Another important advantage is that hoth, the production code and 
automatically executable tests at any level, are modeled by the same UML diagrams. 
Therefore developers use a single homogeneous language to describe implementation 
and tests. This will enhance the availability of tests already at the beginning of the 
coding activities. Similar to the “test first approach” [11,12], sequence diagrams are 
used for test cases and can be taken from the previously modeled requirements. 




Part of the UML-models (mainly class diagrams and statecharts) are used con- 
structively, others are used for test case definition (mainly OCL, sequence and en- 
hanced object diagrams). Fig. 1 illustrates the key mappings. 



3 Agile Modeling: Using Models in Agile Projects 

In the last few years a number of agile methods have heen defined that share a certain 
kind of characteristics, described in [13]. Among these Extreme Programming (XP) 
[4] is the most widely used and discussed method. Some of the XP characteristics are; 
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• It focuses on the primary goal, the production code. Documentation instead is 
widely disregarded, but coding standards are enforced to document the code well. 

• Automated tests are used on all levels. Practical experience shows, that when this 
is properly done, the defect rate is considerably low. Furthermore, the automation 
allows to repeat tests continuously. 

• Very small iterations with continuous integration are enforced and the system is 
kept as simple as possible. 

• Refactoring is used to improve the code structure and tests ensure a low defect 
rate introduced through refactoring. 

The abandoning of documentation is motivated by the gained reduction of workload 
and the observation, that developers don’t trust documents, because these usually are 
out of date. So, XP directly focuses on code. All design activities directly manifest in 
the code. Quality is ensured through strong emphasis on testing activities, ideally on 
development of the tests before the production code (“test first approach” [11]). An 
explicit architectural design phase is abandoned and the architecture emerges during 
coding. Architectural shortcomings are resolved through the application of refactor- 
ing techniques [14,15]. These are transformational techniques to refactor a system in 
small steps to enhance its structure. The concept isn’t new [16], but through availabil- 
ity of tools and its embedding in XP, transformational development now becomes 
widely used. 

When using an executable version of UML to develop the system within an agile 
approach, the development project should become even more efficient. On the one 
hand, through the abstractness of the platform independent models, these models are 
more compact and can more easily be written, read and understood than code. On the 
other hand in classic development projects these models are developed anyway. But, 
increased reuse of these models for later stages now becomes feasible through better 
assistance. Therefore, model-based development as proposed by the MDA-approach 
[6] becomes applicable. The separation of application models and platform specific 
parts that are combined through code generation only exhibits some characteristics of 
aspect oriented programming [17]. These UML-models also serve as up-to-date 
documentation much better than commented code does. 



static analysis 




Fig. 2. The potential uses of UML-models. 
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To summarize, Fig. 2 shows the techniques used on models. This is quite in con- 
trast to [18], where models are only used as informal drawings on the wall without 
further impact. 



4 Model-Based Testing 

There exists a huge variety of testing strategies [19,20]. The use of models for the 
definition of tests and production code can be manifold: 

• Code or at least code frames can be generated from a design model. 

• Test cases can be derived from an analysis or design model that is not used/usable 
for constructive generation of production code. For example behavioral models, 
such as statecharts, can be used to derive test cases that cover states, transitions or 
even paths. 

• The modeling technique itself can be used to describe a test case or at least a part 
thereof. 



expected result and/or 




Fig. 3. Structure of a test modeled with object diagrams (OD), sequence diagram (SD) and the 
Object Constraint Language (OCL). 

The first two uses are already discussed e.g. in [20]. Therefore, in this section we 
concentrate on the development of models that describe tests. A typical test, as shown 
in Fig. 3 consists of a description of the test data, the test driver and an oracle charac- 
terizing the desired test result. In object-oriented environments, the test data can usu- 
ally be described by an object diagram (OD). It shows the necessary objects as well 
as concrete values for their attributes and the linking structure. The test driver can be 
modeled using a simple method call or, if more complex, a sequence diagram (SD). 
An SD has the considerable advantage that not only the triggering method calls can 
be described, but it is possible to model desired interactions and check object states 
during the test run. 

For this purpose, the Object Constraint Language (OCL, [21]) is used. In the se- 
quence diagram in Fig. 4, an OCL constraint at the bottom ensures that the new clos- 
ing time of the auction is set to the time when the bid was submitted (bid.time) plus 
the extension time to allow competitors to react (the auction system containing this 
structure is in part described in [8,22]). Furthermore, it has proven efficient to model 
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the test oracle using a combination of an object diagram and OCL properties. The 
object diagram in this case serves as a property description and can therefore be 
rather incomplete, just focusing on the desired effects. The OCL constraints used can 
also be general invariants or specific property descriptions. 



copper: 

Auction 




:BidPolicv 




iTiminqPolicv 



»trigger» 

handleBid(bid) 



validateBid(bid) 



test driver 



return t 



T 



return OK 

getNewClosihgTime(bid) 






OCL constraints 
describe 

properties during 
the test run 



t.time == 

bid.time + extensionTime 




Fig. 4. A sequence diagram (SD) describing the trigger of a test driver and some test interac- 
tions as well as an OCL property that holds at that point of time. 



As already mentioned, being able to use the same, coherent language to model the 
production system and the tests allows for a good integration between both tasks. It 
allows the developer to immediately define tests for the constructive model devel- 
oped. It is imaginable that in a kind of “test-first modeling approach” the test data in 
form of possible object structures is developed before the actual implementation. 



5 Model Evolution Using Automated Tests 

Neither code nor models are initially correct. For code, many sources of incorrectness 
can rather easily be analyzed using type checkers of compilers and automated tests 
that run on the code. For models this is usually a problem that leaves many errors 
undetected in analysis and design models. This is particularly critical as conceptual 
errors in these models are rather expensive if detected only late in the development 
process. The use of code generation and automated tests helps to identify errors in 
these models. 

Besides detecting errors, which might even result from considerable architectural 
flaws, nowadays, it is expected that the development and maintenance process is 
capable of being flexible enough to dynamically react on changing requirements. In 
particular, enhanced business logic or additional functionality should be added rap- 
idly to existing systems, without necessarily undergo a major re-development or re- 
engineering phase. This can be achieved at best, if techniques are available that sys- 
tematically evolve the system using transformations. To make such an approach man- 
ageable, the refactoring techniques for lava [14] have proven that a comprehensible 
set of small and systematically applicable transformation rules seems optimal. Trans- 
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formations, however, cannot only be applied to code, but to any kind of model. A 
number of possible applications are discussed in [16]. 




Fig. 5. Transformations to improve the quality of design opposed to development steps that add 
functionality. 

Having a comprehensible set of model transformations at hand, model evolution 
becomes a crucial step in software development and maintenance. Architectural and 
design flaws can then be more easily corrected, superfluous functionality and struc- 
ture removed, structure for additional functionality or behavioral optimizations be 
adapted, because models are more abstract, exhibit higher-level architectural and 
design information in a better way. During development, the situation can roughly be 
described with Fig. 5. It shows the dimension of functionality (measured for example 
in function points) and the “quality of design” (without a good metrics and therefore 
as informal concept). The development process tries to reach the 100% functionality 
while at the same time targets a reasonable good design. 

The core development process ideally consists of step from two categories: 

• Development (or programming) steps add functionality. But usually they in prac- 
tice also introduce “erosion” of the design quality. For example repeated adding 
of new methods to a class overloads that class, simplifications of the code might 
come up, etc. Thus design quality usually suffers. 

• Transformational (refactoring) steps build the second category. They improve 
structure and design, without changing the “externally observable behavior”. 

Two simple transformation rules on a class diagram are shown in Fig. 6. The figure 
shows two steps that move a method and an attribute upward in the inheritance hier- 
archy. The upward move of the attribute is accompanied by the only context condi- 
tion, that the other class “Guest” didn’t have an attribute with the same name yet. In 
contrast, moving the method may be more involved. In particular, if both existing 
method bodies are different, there are several possibilities: (1) Move up one method 
implementation and have it overridden in the other class. (2) Just add the method as 
abstract signature in the superclass. (3) Adapt the method implementations in such a 
way that common parts can be moved upward. This can for example be achieved by 
factoring differences between the two implementations of “checkPasswd” into 
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smaller methods, such that at the end a common method body for “checkPasswd” 
remains. As a context condition, the moved method may not use attributes that are 
available in the subclasses only. 




Fig. 6. Two transformational steps moving an attribute and a method along the hierarchy. 



Many of the necessary transformation steps are as simple as the upward move of 
an attribute. However, others are more involved and their application comes with a 
larger set of context conditions and accompanying steps similar to the adaptation 
necessary for the “checkPasswd” method. These of course need automated assistance. 
The power of these simple and manageable transformation steps comes from the 
possibility to combine them and evolve complex designs in a systematic and traceable 
way. 

Following the definition on refactoring [14], we use transformational steps for 
structure enhancement that does not affect “externally visible behavior”. For example 
both transformations shown in Fig. 6 do not affect the external behavior if made 
properly. 

By “externally visible behavior” Fowler in [14] basically refers to behavioral 
changes visible to the user. This can be generalized by introducing an abstract “sys- 
tem border”. This border serves as interface to the user, but may also act as interface 
to other systems. Furthermore, in a hierarchically structured system, we may enforce 
behavioral equivalence for “subsystem borders” already. It is therefore necessary to 
explicitly describe, which kind of behavior is regarded as externally visible. For this 
purpose tests are the appropriate technique to describe behavior, because (1) tests are 
already available through the development process and (2) tests are automated which 
allows us to check the effect of a transformation through inexpensive, automated 
regression testing. 

A test case thus acts as an “observer” of the behavior of a system under a certain 
condition. This condition is also described by the test case, namely through the setup, 
the test driver and the observations made by the test. Fig. 7 illustrates this situation. 

Fig. 7 also shows that tests do not necessarily constrain their observation to “exter- 
nally visible behavior”, but can make observations on local structure, internal interac- 
tions or state properties even during the system run. Therefore, it is essential to iden- 
tify, which tests are regarded as “internal” and are evolving together with the trans- 
formed system and which tests need to remain unchanged, because they describe 
external properties of the system. Tests in one categorization can roughly be divided 
into unit tests, integration tests and acceptance tests. 
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test = driver and “observer” 




Unit and integration tests focus on small parts of the system (classes or subsystems) 
and usually take a deep look into system internals. It therefore isn’t surprising that 
these kinds of tests can become erroneous after a transformation of the underlying 
models. Indeed, these tests are usually transformed together with the code models. 
For example, moving an attribute upward as shown in Fig. 6 induces object diagrams 
with Guest-objects to be adapted accordingly by providing a concrete value for that 
attribute. In this case it may even be of interest to clone tests in order to allow for 
different values to be tested. Contrary, tests may also become obsolete if functionality 
or data structure is simplified. The task of transforming test models together with 
production code models can therefore not be fully automated. 

Unit and integration tests are usually provided by the developer or test teams that 
have access to the systems internal details. Therefore, these are usually “glass box 
tests”. Acceptance tests, instead, are “black box” tests that are provided by the user 
(although again realized by developers) and describe external properties of the sys- 
tem. These tests must be a lot more robust against changes of internal structure. Fig. 8 
illustrates a commuting diagram that shows how an observation remains invariant 
under a test. 




Fig. 8. The transformed system model is invariant under a test observation. 
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To achieve robustness, acceptance tests should be modeled against the published 
interfaces of a system. In this context “published” means that parts of the system that 
are explicitly marked as externally visible and therefore usually rather stable. Only 
explicit changes of requirements lead to changes of these tests and indeed the adapta- 
tion of requirements can very well be demonstrated through adaptation of these test 
models followed by the transformations necessary to meet these tests afterwards in a 
“test-first-approach”. An adapted approach also works for changes in the interfaces 
between subsystems. 

To increase stability of acceptance tests in transformational development, it has 
proven useful to follow a number of standards for test model development. These are 
similar to coding standards and have been found useful already before the combina- 
tion with the transformational approach: 

• In general an acceptance test should be abstract, by not trying to determine every 
detail of the tested part of the system. 

• A test oracle should not try to determine every part of the output and the resulting 
data structure, but concentrate on important details, e.g. by ignoring uninteresting 
objects and attribute values. 

• OCL property descriptions can often be used to model a range of possible results 
instead of determining one concrete result. 

• Query-methods should be used instead of direct attribute access. This is more sta- 
ble when the data structure is changed. 

• It should not be tried to observe internal interactions during the system run. This 
means that sequence diagrams that are used as test drivers concentrate on triggers 
and on interactions with the system border only. 

• Explicitly published interfaces that are regarded as highly stable should be intro- 
duced and acceptance tests should focus on these interfaces. 



6 Conclusions 

The proposal made in this paper can be summarized as a pragmatic approach to 
model-based software development. It uses models as primary artifact for require- 
ments and design documentation, code generation and test case development. A trans- 
formational approach to model evolution allows an efficient adaption of the system to 
changing requirements and technology, optimizing architectural design and fixing 
bugs. To ensure the quality of such an evolving system, intensive sets of test cases are 
used. They are modeled in the same language, namely UML, and thus exhibit a good 
integration and allow to model system and tests in parallel. 

However, the methodology sketched here still is a major proposal, adequate to be 
described in proceedings about the future of software technology. Major efforts still 
have to be done. On the one hand, even though initial works on various model trans- 
formations do exist, they are not very well put in context and not very well integrated 
with the UML in its current version. Lor example, it remains a challenge to provide 
automated support for the adaptation necessary for sequence diagrams that are af- 
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fected by statechart changes. Similarly, object diagrams usually are affected when the 
underlying class diagrams are changed. At least in the latter case, a number of results 
can be reused from the area of database schema evolution. But neither the pragmatic 
methodology, nor theoretic underpinning are very well explored yet, even though 
there is currently intensive research in the area of test theory development. 

On the other hand, model based evolution will become successful only if well as- 
sisted by tools. This includes parameterized code generators for the system as well as 
for executable test drivers, analysis tools and comfortable help for systematic trans- 
formations on models. Today, there is not yet enough progress in these direction. 

As a further obstacle, these new techniques, namely an executable sublanguage of 
the UML as well as a lightweight methodological use of models in a development 
process are both a challenge to traditional software engineering. They exhibit new 
possibilities and problems. Using executable UML allows to program in a more ab- 
stract and efficient way. This may finally downsize projects and decrease costs. The 
free resources can alternatively be used within the project for additional validation 
activities, such as reviews, additional tests or even a verification of critical parts of 
the system. Techniques such as refactoring and test-first design will change software 
engineering and add new elements to its portfolio. 

To summarize, models can and should be used as described in this paper, but of 
course they are not restricted to. Instead it should be possible to have a variety of 
sophisticated analysis and manipulation techniques available that ideally operate on 
the same notations. These techniques should be used whenever appropriate. Even 
though, data and control flow techniques, model checking or even interactive 
verification techniques are already available, they still have to find their broad 
application to models. 

The Model Driven Architecture (MDA) [6] initiative from the OMG has currently 
received lots of interest and several tools and approaches like “executable UML” are 
coming up to assist this approach. However, in the MDA community there is gener- 
ally a belief that MDA only works for large and rather inflexibly run projects. It may 
therefore remain a challenging task, to derive efficient tools as described above and to 
adapt the currently used development processes to this very model-centric and agile 
development process. 
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Abstract. The software architect is concerned with both functional and non- 
functional design. An important task in functional design is the adaptation of 
a component’s provided interface for use by other components. In non-functional 
analysis the focus is rather on the prediction and reasoning about reliability and 
performance properties. We present a method for automatic adaptation, based upon 
parameterised contracts. This concept extends the notion of design-by-contract 
from precondition, postcondition and invariant assertions on objects to dynamic 
protocol descriptions for required and provided interfaces of components. We in- 
troduce a novel state machine based model, called dependent finite state machines 
(DFSMs), and show how DFSMs provide a natural framework for both automatic 
component adaptation and computational reasoning about timing properties of 
components and architectures. We use the well-known production cell example 
for demonstrating our architectural description language. 

Keywords: automated interface adaptation, component-based interface specifica- 
tion, component-based prediction, finite state machines, production cell, protocol 
types, parameterised contracts, software architecture. 



1 Introduction 

The software architect is concerned with both functional and non-functional design. 
In component-based architectures, the former task can involve specifying, choosing, 
adapting, analysing and connecting components. The latter task involves analysis over 
properties such as reliability, availability, or performance. As system complexity in- 
creases, so do the costs associated with those tasks. It is therefore desirable to define 
methods and formalisms that can simultaneously address functional and non-functional 
concerns. 

As a step in this direction we introduce a new modelling paradigm, called Dependent 
Finite State Machines (DFSMs); then we present component-oriented and distributed 
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software architecting features that extend the traditional object-oriented view of interface 
contracts to parameterised contracts. Previous presentations of parameterised contracts 
used finite state machine (FSM) descriptions of components for adaptation [21]. In this 
paper, we show how DFSMs permit compositional descriptions for components, making 
parameterised contracts more readily applicable to architecture description and analy- 
sis. DFSMs can also be used for the adaptation of interface functionality. Component 
adaptation is a well-known problem in software engineering. Components are designed 
to provide interfaces for external use but also to use interfaces of other components. It is 
often necessary to adapt a component’s provided interface for use by another component. 
This is a costly task, and some level of automation is useful. 

Our method for automatic adaptation relies on parameterised contracts, which adapt 
the notion of design-by-contract from objects to components and from precondition, 
postcondition and invariant assertions to dynamic protocol descriptions. Parameterised 
contracts define the contractual use of a component for composition with other compo- 
nents in some architecture. This permits the automatic adaptation through re-computation 
of a component’s provided functionality depending on the functionalities required of 
other components. Conversely we can compute the minimal set of required services for 
a selected subset of a component’s provided services. 

Parameterised contracts can also be applied to non-functional analysis because pa- 
rameterised contracts allow us to express how a component’s non-functional behaviour 
depends on the behaviour of the components it uses. For example, the worst-case time of 
a real-time component may be given as a function of the time it takes to perform critical 
system services that are provided by the components it uses and that are mapped into 
the DFSM model. That the model allows us to address other non-functional properties 
as well has been shown for reliability in [19]. 

The rest of the paper is organised as follows. The running example is briefly discussed 
in section 2. Section 3 introduces DFSMs, architectural compositions on such machines 
and their role in the Rich Architectural Description Language, radl [20]. In section 4 
we discuss design-by-contract for components and define parameterised contracts. Then 
we apply the DFSMs and parameterised contracts to model component and architecture 
adaptation and timing analysis. In section 6 we discuss related work and section 7 
concludes. 

2 Example Application 

To illustrate our concepts and models, we use a variant of the production cell introduced 
in [10]. It describes the operation of a metal processing factory located in the southwest 
of Germany. A VRML' reconstruction of the production cell is depicted in Fig. 1. In 
this example we assume an external gadget to deposit individual metal blanks on the 
left end of the feed belt (left front) one after the other in arbitrary time intervals. 
The belt conveys these blanks to the rotary table at the belt’s other end. Once the 
blank has been passed over, the table moves up and slightly rotates to bring the blank 
into a position and onto a level from where robot arm 1 can pick it up. After arml has 
been loaded, the robot base rotates counter-clockwise into a position in which arml 

* Virtual Reality Modelling Language. 
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Fig. 1. Production Cell. 



points at the press to introduce the blank into the press where it is forged while the 
movable plate of the press is closed. 

To increase the use of the press, the robot is equipped with a second arm. Arm2 picks 
up the part forged in the previous cycle from the press, the robot rotates counter-clockwise 
until arm 2 points toward the deposit belt and unloads the piece of metal on that 
belt. This belt moves processed parts to its other end. From here they are removed one by 
one by a second gadget in the environment. Arms 1 and arm2 are mounted on different 
vertical levels and access the press while its movable plate rests in two different vertical 
levels (middle and bottom, respectively). The arms can take load with their grippers 
independently through magnets. They can also be extended or retracted horizontally. 
Sensors monitor the load and unload zones of the conveyor belts and signal significant 
positions of certain actuators. We assume that the robot, the press and the conveyor belts 
have their own software controller. These controllers communicate by some form of 
message passing. 

In the rest of the paper we abbreviate the various operations according to the mapping 
shown in Table 1 . The following operations are non atomic : 1 o ad extends the arm, takes 
a load and retracts the arm again; unload extends the arm, drops the load and retracts 
the arm again; process moves the plate up from the middle position and thereby forges 
a blank placed on the movable plate, then moves the plate two levels down; remove 
removes the processed blank and moves the press plate one level up. 

3 Foundations 

This section introduces the basic notions underlying the radl architectural description 
language. It presents finite state machine models that provide semantics to interaction 
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Table 1. Action abbreviations with worst-case time. 



1 Actuator actions 


on 


switch gripper magnet on 


off 


switch gripper magnet off 


in 


switch arm expander to pull in arm 


out 


switch arm expander to push out arm 


tl 


turn robot base one step left 


tr 


turn robot base one step right 


up 


move press plate one level up 


down 


move press plate one level down 


1 Controller actions with time 


take 


take load with gripper magnet 


10 


drop 


drop load held by gripper magnet 


10 


ret 


retract arm 


300 


ext 


extend arm 


300 


row 


rotate robot base clockwise by one position 


400 


rcc 


rotate robot base counter clockwise by one position 


400 


press 


move press plate one level up 


30 


remove 


remove processed blank 


10 


bot 


signal bottom position 


2 


mid 


signal middle position 


2 


rup 


elevate rotary table 


40 


rdown 


lower rotary table 


40 


load 


load arm 




unload 


unload arm 





protocols. Such protocols form an integral part of radl interfaces. A translation relation 
serves to connect a component’s provided and required interfaces. Dependent finite state 
machines lay the foundation of parameterised contracts presented in section 4. 



3.1 Component Based Software Architectures 

Based on extensions of design-by-contract to distributed systems’ components, the radl 
architectural description language (ADL) was originally described in [20] and has been 
extended later in [17]. In radl, a system is decomposed into hierarchies of kens, linked 
to each other by connections between gates. 

Kens are coarse-grain, computational entities typically communicating by message 
passing via interface objects. Kens can represent components or other architectural units. 
Fig. 2 shows the kens of the production cell architecture as boxes. Primitive Kens are the 
lowest-level kens. They are usually implemented as binary components, whose internal 
structure is transparent to the architect. In our example, the subkens of Robot, Arml, 
Arm2 and Base, are primitive kens. Composite kens address compositionality. They 
represent hierarchically organised collections of kens with well-defined connections. In 
our example. Robot and the production cell system are composite kens. 

Gates protect kens, which cannot be directly accessed. All calls, all data commu- 
nicated and all objects migrated to a ken must come through gates. They represent 
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Fig. 2. Production Cell Architecture. 



interface types and objects. In architecture diagrams, gates are represented by triangles, 
the direction of which indicates control, not necessarily signal flow. For example, the 
Robot controls the press via a gate, despite the fact that acknowledgement signals may 
flow back via this same gate. Depending on its role as controlled or controlling, a gate 
is provided or required (short PGate and RGate). Connections are established between 
gates as part of the architectural composition, like in Darwin [12], at deployment or at 
run time (dynamic connections are not needed for our example). 

Kens and gates are analogous to components and services, respectively, in Darwin; 
to components and ports, respectively, in C2 and ACME; or to processes and ports in 
MetaH [14]. However, the radl distinguishes different kinds of components reflecting 
their architectural role in distributed systems analysis, design and implementation. 



3.2 Finite State Machine Models of Component and Connector Protocols 

In radl protocols are part of contracts. Protocols are types. A protocol type is deflned as 
a set of valid sequences of service calls and is represented by FSMs. For example, the 
Expander FSM in Fig. 3 (left) permits sequences { ext , ret ) * . 

Services have parameter and result types specified in signatures. Signatures are part 
of interface definitions in radl and are used in assertions. We distinguish between input, 
output and hidden symbols in signatures. Relative to a component of interest, the inputs 
are controlled from outside, they are incoming service calls; the outputs correspond to 
outgoing calls; they are controlled by the component. The hidden symbols represent 
auxiliary tests and actions. The protocols in terms of FSMs do not depend on service 
parameters, although notations such as UML state charts permit passing of such pa- 
rameters to actions associated with protocol elements. Both PGates and RGates have 
associated interface specifications including protocol types for interoperability checking 
or automatic adaptation. 

In elementary components such as a robot arm expander, gripper magnet, robot base, 
or press we permit PGates to model machine interfaces, i.e., operations that directly 
control the hardware, notably sensors and actuators. These gates are ungrounded, i.e., 
unconnected terminator gates. They can be viewed as the abstract machine of a real- 
world physical primitive ken not shown. The terminator PGate models the full physical 
behaviour, i.e., all possible actions of the actuator including destructive actions. For 
example, the arm expander can either be extended or retracted (note that we are only 
interested in the machine’s discrete behaviour). Hence, the two machine operations 
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Fig. 3. A renaming Expander =Switch [on : ext, off: ret] (left) ; a substitution with ac- 
knowledgement Press=Switch [on : (up, down, down, "bot) , off: (up, 'mid) ] 

(center left); the robot Base PGate actuator protocol (center right) can physically reach an unsafe 
state (destruction in 5); the Arm protocol (right) is the product of an Expander and Gripper. 



in and out can only be applied in sequence. This behaviour is a signature renaming 
Arm=Switch [on : in, off: out] , of the Switch type, which maps on to in 
and of f to out. We use a caret (' ) to mark output symbols (signals). 



Protocol Types and Conformance. Formal definitions of FSMs and their relationships 
to formal languages and Boolean algebra can be found in automata theory textbooks. 
For brevity, we use all operations on regular language as operations on FSMs, too, and 
loosely identify an FSM A and the language La representing sets of transition sequences 
leading from the initial state to some final state. Since we treat protocols as a separate 
aspect of interface types in radl, we define a protocol type as the equivalence class of 
FSMs A generating the same language La- Then the inclusion of FSMs lends itself as 
a notion of protocol subtyping. 

Definition 1. Given two protocols A and A is a protocol subtype of B (denoted 
A < B) iff Lb C La- In this case we also say that A conforms to B- 

If A conforms to B, then all sequences expected according to a protocol B are acceptable 
by protocol A. A may optionally allow more sequences than B- We should explicitly 
mention the fact that the equivalence and conformance of two protocol type specifications 
A and B is decidable. 

A common constructive form of conformance is the use of restriction A\b = {a: G 
^1 (3 ^)i:b S B}, which selects only traces in A that observe the protocol B- Here, (x ) b 
({A)b) denotes the projection of trace x (of language A) to symbols in B, deleting 
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symbols^ not in B. For example, we can derive an adapter called Saf eBase through 
a restriction of robot Base in Fig. 3 by simply subtracting state 5, which represents 
the destructive state into which the robot can get by overturning the base in left or right 
direction. Saf eBase, which is part of the robot base controller’s provides interface, 
prevents such a destructive move to happen. Obviously, we have that isase < ^saf eBase- 

All the above operators are decidable. Not only can static configurations of kens 
and gates be checked for protocol-type correctness (under conformance) but it is also 
realistic to perform conformance checks dynamically when components are deployed 
or loaded. 

3.3 Complex Connectors and Adapters 

In general, interoperability may require more complex translations from required to 
provided gates, the two end points of a connection. Sometimes translations involve 
several gates. To this end we partition the alphabet into three pairwise disjoint sets 
S = lUHUO: the input /, hidden H and output symbols O. Furthermore we assume S 
is equipped with a reflexive and symmetric relation D, called dependency. S is then also 
called a dependence alphabet, which uniquely extends (sequential) words into (parallel) 
partial orders. Dependence alphabets extend regular languages to parallel trace languages 
[5] and regular expressions (finite state automata) to rational star-connected expressions 
(or Petri nets that are automata products, respectively) [16]. Modularity and closure 
properties are preserved in this extension. Intuitively the complement Cd of D is viewed 
as a concurrency relation. With aCrrb, the word ab is equivalent to ba and represents 
the single-step parallel transition of a and b that takes time t{ab) = max{t{a) ,t{b)) if 
a symbol s & S takes time t{s). In contrast, t{ab) = t{a) + t{b) if aDb. Dependence 
alphabets extend our protocols to protocols for trace languages. 

Now we can “observe” input, hidden and output subprotocols in trace languages La 
using the corresponding projections {La)i, {La)h, and {La)o^ which “delete” symbols 
not in the subalphabet listed. A protocol type A over a partitioned dependence alphabet 
can then be viewed as a translation from parallel inputs to parallel outputs. 

Definition 2. The translation relation (short translation) of a protocol type A, Oa Q 
{La) I X {La)o w defined by the minimal set of pairs satisfying 

wjOawo if w G La- 

0, the function taking protocol types to their translations as defined above, is called the 
translation functor. 

Due to this underlying translation we call the languages and FSMs on partitioned 
alphabets translator protocol type. We use these types for characterising the dependency 
a component’s computation establishes between its provided and required gates. 

Theorem 1. Protocol translation types are closed under the usual regular language 
operations. 

^ The result of a projection is usually not a sublanguage. However restrictions are sublanguages 
defined via intermediate projections. 




Predictable Component Architectures Using Dependent Finite State Machines 



317 



Note that, in contrast, finite state transducers^ are not closed under all regular lan- 
guage operations. 

Using the algebra of translations with regular language operators, we can now build 
complex adapters and connectors for true parallel (trace) languages starting from simple 
input- and output-only gates. Synchronised and asynchronous call abstractions may be 
defined by substitutions as shown in Fig. 3. In [22], we showed the construction of more 
complex adapters for synchronising concurrent protocols. 

3.4 Dependent FSMs 

Protocol subtyping permits decidable conformance tests - yet that is not sufficient for 
dealing effectively with non-functional properties. Protocols types as defined above 
capture functional interface types - performance analysis often requires an understanding 
of system configuration partly at the level of instances permitting the distinction of two 
separate or parallel entities from two tightly synchronised or even identical instances 
(possibly of the same type). This observation has led architecture definition languages 
such as our radl or the forthcoming UML2 architecture definition to view gates (and 
their connections) as instances of such protocol types and group multiple gates into 
ports and associate multiple ports with a single component. In addition, components 
are intrinsically open. Their performance properties critically depend on properties of 
external components. For example, the reliability of a component, from the viewpoint 
of its provided services is not only a function of its own implementation but also of the 
reliability of invoked external components including those in the underlying platform 
(for instance, middleware framework, operating system, hardware). Worse, each of the 
invoked external services must also be factored into the invoking component’s reliability 
in a different way. For example, if RGate R is accessed many times while RGate S 
is accessed infrequently, then the reliability of R must weigh in considerably more 
significantly than that of S. Thus components are intrinsically parameterised by the 
protocols of those gates and the component translation protocol acts on those parameters. 

The above aspects are captured in the following notion of dependent FSMs. They es- 
tablish ( 1 ) the association between gates and a component, (2) the translation relationship 
the component imposes on its gates, and (3) a hierarchical structuring of this transla- 
tion type. This enables us to build architectural networks of dependent components and 
compute dependent FSMs from simpler ones following the architectural compositions 
from primitive to composite gates and components. 

Definition 3. A dependent FSM, short DFSM, is a triple D = (i?, A, P), where P = 
{Pi)i<i is a family of FSMs, called the provided parameters of D, R = {Rj)j<m is 
a family of FSMs, called the required parameters of D, and, A is an FSM called the 
abstract effect or abstract machine of D, with l,m G N. Furthermore, we require that 
Sp = I and Sp = O and call D consistent if the following two conditions hold: 

1. {A)p^ < Pi, i.e. A accepts all inputs acceptable to the provided gates. 

2. for all Ri G R we have that Rj < {A)p., i.e., A generates outputs acceptable to 
the required gates. 

^ Functions from input to output languages defined by Mealy machines. 
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Note that the above notion of type consistency adds constraints beyond pure con- 
nection interoperability. A collection of DFSM& with gate bindings, which impose so- 
called R-P dependencies on an architecture, can now be treated as architectural protocols. 
Beyond the interface dehnition P and R, obviously, a DFSM includes an abstract model 
(A) of the dependency imposed on these interfaces by the component implementation. 
We call this P-R dependency (see also Fig. 4). As A models aspects of the implemen- 
tation, in whatever abstraction level, we promote a grey-box approach to components. 
For each provided gate Pi and each provided (input) symbol s (in fact for each input 
sequence s), the translation type Oa defines the output language sOa- 

By extension, the output language of P by considering IJi<m ^p-Oa is the output 
language of D. 

Since regular languages are closed under the operations in the above definition, the 
following proposition is noteworthy: 

Corollary 1. Equivalence and inclusion of DFSMs are decidable. There is a straight- 
forward algorithm for DFSM minimisation implied by Definition 2. 

Notice that this result holds for DFSMs over partitioned independence alphabets. 
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Fig. 4. P-R dependency models consistency 
of interfaces with component behaviour 
(Def. 3), while R-P dependency models con- 
formance (Def. 1). 



Fig. 5. Composition constrained by syn- 
chronisation constraint S, which is actu- 
alised by different parameters in different 
configurations. 



4 Generalizing Parameterised Contracts 

When addressing the contractual use of components, we need to distinguish between 
the use of a component at run time or at composition time. In the first case, one is 
actually using the methods of the component. According to Meyer’s design-by-contract 
principle [15], the contractual use of a component at run time implies that a method’s 
precondition is met by the caller while it must ensure the postcondition itself. To lift this 
notion from the level of methods to the level of the components, we view the required 
interface specification as the component’s precondition, and the provided interface as 
the component’s postcondition. 

We denote the precondition of a component c by prCc and its postcondition by paste- 
For checking whether a component c can be replaced safely by a component c ' , one has to 
ensure that the contract of d is a subcontract of c. The notion of a subcontract is described 
in [15, p. 573] like contravariant typing for methods: A contract c' is a subcontract of 
contract c iff 



prep ^ prCc A postp > post, 



(1) 
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where > means “stronger”, i.e., subtype. If prCc and postc are predicates, > corresponds 
to In our DFSM semantics for protocol types, > is subtyping. 

To check the interoperability (i.e., R-P dependency) between components c and c' 
(as defined in section 3.4, see also Fig. 4), one has to check whether: 

prcc < postc' ■ ( 2 ) 

When extending these concepts to DFSM enriched interfaces, we can consider the pre- 
condition of a component as the set of required method call sequences, i.e., the shuffle 
product of the languages accepted by the FSMs of the RGates. The postcondition is the 
set of provided call sequences (i.e., the union of the languages accepted by the FSMs 
of the PGates). In this case, the checks described in formulas (1) and (2) boil down to 
inclusion checking. 

While interoperability tests check the required interface of a component against the 
provided interface of another component, parameterised contracts link the provided 
interface of one component to the requires interface of the same component (see P-R de- 
pendency in Fig. 4). Parameterised contracts were formally introduced in a more limited 
fashion in [18]. Here we extend these notions to work with multiple gates and partial 
actualisation. Actualisation can, e.g., be used to impose synchronisation constraints on 
the composition of protocols of composite components. 

An example is shown in Fig. 5. The contract of a Robot instance is specified as 
the parallel composition of the contracts of its constituent component instances Arml 
(Al), Arm2 (A2) and Base (B) constrained by parameter S. A typical actualisation of 
S would be a sequential organisation of safety-critical controller actions: 

S = Al.load. B.rcc, A2.1oad, B.rcc, Al. unload, B.rcc, A2. unload, B.ret (3) 

where B . ret = B . row, B . row, B . row. Note also that the controller actions rcw and 
rcc control the actuator actions tl and tr, respectively (see also Table 1). 

Originally, the concept of parameterised contracts was motivated by the observation 
that in practice often only a subset of a component’s functionality is used. So, even if 
the environment offers less functionality than required, the component might still be 
able to provide its own full functionality. The binding of a formally required gate to an 
actual non-conforming component gate is then viewed as parameter actualisation and 
the protocol algebra is used to compute exactly the weakest provided parameters that 
can still be offered in the given context. The parameterisation modelled with DFSMs 
below goes beyond such adaptations. It permits non-functional parameterisation such as 
variations in synchronisation constraints (S' above), timing, and other properties. 

For a PGate Pi (or RGate Ri), we define the set of all subtypes of this gate as 
(or Ri, respectively). The set of all possible preconditions Prec (or postconditions 
Postc) of a component C is then the set of all possible tuples in Rq x • • • x Rj-i (or 
Pq X • • • X Pm-i, respectively). We denote the union of all these tuple sets by Typ*. 

The P-R dependency between the PGates and the RGates of a component C (as 
introduced in Section 3.4) can be written as C[Pre — Post] and interpreted as mapping 
between corresponding tuples. A parameterised contract is any mapping <P : Typ* — 
Typ* that is total, bijective and monotone with respect to > (hence from prei > 
prc 2 we can deduce <l>{prei) > d>{pre 2 ))- is called parameterised contract since it 
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parameterises the postcondition with the precondition of the component and vice versa. 
It can he considered as a generalisation of “classical contracts”, which use a fixed pre- 
and postcondition. 

If component A uses only a subset of the functionality offered by B, we compute a 
new required interface for B with the parameterised contract ^ b '■ 

‘^B^i'reqA n ptovb) =■ regg C reqB (4) 

This gives us a subset of the functionality B requires from C. The new required interface 
req'B is weaker (requires possibly less) than the original required interface reqB ■= 
<Pg^{provB) (but not more) since <Pb is monotone and reqA H provB C provB- 

For example, in a different configuration of the production cell we might have another 
type of physical Press, which has only one access level (e.g., "mid but not "bot) 
and thus only admits a behaviour equivalent to the Switch protocol (up, down)*, 
which defines the required interface of the new Press. As a consequence, the provided 
interface of the Press is restricted to (up, down, "mid)* and the trigger bot for 
a2 . load in the Robot provided protocol disappears. This would imply that Arm 2 
cannot be used in this production cell configuration. 

Likewise, if component C does not provide all the functionality required by B, one 
can compute a new provided interface prov'B with (!>b'- 

<pB{reqB D prove) =■ provB C provB (5) 

Since is monotone, is monotone as well. With reqB A prove Q regB we have 
prov'g C provB ■= ^{reqB)- 

Since is monotone and bijective, the required parameterised contract always has 
to return the strongest provided interface (strongest postcondition), while the provided 
parameterised contract always returns the weakest required interface (weakest precon- 
dition‘d). 

5 Analysing Timing Properties 

In an industrial cooperation in the area of embedded control systems, the first author is 
currently developing component-based methods for predicting worst case time based on 
DFSMs with timed transitions. Here a set of DFSMs represents a real-time distributed 
control system. We solve the problem with a one-pass algorithm computing the maxi- 
mum time of all paths ending in a state before adding the times for successive transitions 
following from that state. We assume bounded loops (which corresponds to the require- 
ments for function blocks) and rely on a well-formedness restriction for intertwined 
loops. 

The plain algorithm is based on graph theory and allows us to compute time bottom 
up and compositionally in terms of the component machines of a DFSM. Parameter- 
isation allows us to actualise synchronisation constraints and update the time models. 
Here, synchronisation constraints are viewed as required gates that are provided at con- 
figuration or deployment time (see also Fig. 5). 

Note the similarity to the wp-calculus. 
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For the composition given in Fig. 5, the synchronisation constraint S specified in (3) 
and the time estimates for primitive controller actions given in Table 1 , the cycle time 
of the cell core is 

4 * (300 + 10 + 300) + 6 * 400 + 8 * 2.5 = 4860 (i.e., 4.9sec) 

if we assume the worst-case synchronisation time is 2.5(msec). 

The synchronisation constraint in (3) is overly conservative as it imposes a tight 
sequential order on the robot’s actions. It is, however, safe to relax the constraint such 
that the arm expander movements and base rotations can overlap in time. An actualisation 
of the Robo t composition with the following relaxed constraint and the same elementary 
times 

s' = Al.M.take, B.rcc, A2.M.take, B.rcc, Al.M.drop, B.rcc, A2.M.drop, B.ret (6) 

relaxes the worst-case execution time to: 4 * 10 -f 6 * 400 -f 8 * 2.5 = 2460 (i.e., 2.5sec) 
because f(ret) = f(exp) < f(rcc) = f(rcw). Now the critical trace does not include 
the expander movements of the arms and hence the cycle time of the core cell is approx- 
imately halved. Note that this relaxation is a change of interaction constraints between 
robot arml and robot base, i.e., internal to the robot. In general, such relaxations may 
invalidate safety invariants, which must therefore be re-established. 

In general, worst-case execution time models are only compositional under certain 
sufficient constraints for well-behaviour. For example, if we rely on failure-free syn- 
chronisation and deadlock freedom, our time models are compositional. This reliance is 
a proof obligation, which may or may not require access to the details of the components 
or the environment they are working in. Therefore, depending on the component model 
chosen or the compositions considered, this premise itself may not be compositional. 

6 Related Work 

In a series of papers, we have explored aspects of our approach for a range of areas, 
such as modelling transactional contexts [17] and adapting component protocols [22]. 
This paper is the first time we have used DFSMs and parameterised contracts as a single 
unifying framework for adaptation and non-functional analysis. 

Our basic approach to syntax and overall behavioural semantics is similar to that 
of other ADLs [14]. Some form of semantics is used to define models of the behaviour 
of basic components. For example, the semantics of Darwin [12] has been successfully 
modelled with the 7r-calculus and labelled transition systems [13]; Rapide [11] uses 
partially ordered event sets and Wright [1] makes use of a variant of CSR The language 
of the ADL is used primarily to impose structure on a system’s behaviour, expressing 
its composition from components. Composition-forming constructs are associated with 
semantic functions, which are used to analyse a composite component’s behavioural 
semantics in terms of its subcomponents’ behavioural semantics. Typically, such analysis 
involves establishing global checks such as liveness and safety properties. 

Cheung used architectural information in combination with usage profiles for pre- 
dicting system reliability following the flow of control across component boundaries [4] . 
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Wang extended Cheung’s work by analysing different architectural styles such as pipelines 
or hlters [24]. This line of work seems to aim at availability. Moreover, it is not open for 
parameterisation and compositionality. 

Hamlet in [7] advocates a statistical view of component-oriented architectures. He 
identihes the need for usage prohles clearly but requires source code for his computations. 
In contrast, our method works with binary black-box components and architectural 
assembly and it recognises the strong influence of required components’ reliability. 

In [6] Frolund and Koistinen provide a syntax for defining and specifying quality 
of service attributes. Similar to our work, they emphasise the contractual use of qual- 
ity of service attributes. However, they specify reliability as constant, while we use 
parameterised contracts for computing context-dependent component reliability. 

To the best of our knowledge, little work has been done previously on combining 
protocol-based adaptation and non-functional prediction with an ADL. Parameterised 
contracts allow us to model functional and non-functional properties and dependencies 
in one framework. State machines are a well-known notation for protocol specification 
and adaptor generation [26] . There is a range of adaptation mechanisms that do not use 
interface information [3], such as delegation, wrappers, superimposition, or metapro- 
gramming [9] . Since radl strongly depends on protocol information, tools for generating 
provided FSMs and abstract machine DFSMs through control-flow analysis of code [8] 
are vital. Furthermore, tool support exists for deriving FSMs from message sequence 
charts [25]. 

7 Conclusions 

The functionality provided by a component always depends on the functionality received 
from its environment. Hence, especially in those systems in which many different con- 
hgurations and environments exist, the ability to perform fine-grained adaptations and to 
model and predict non-functional properties is crucial. We presented our ADL radl as a 
unihed framework for specifying and computing functional and non-functional proper- 
ties of component-based software-architectures. The underlying principle for automatic 
protocol adaptation and reliability prediction are parameterised contracts, which we pre- 
sented as a generalisation of interoperability checks between components (i.e., classical 
contracts of components). We introduced DFSMs as a novel model for specifying pa- 
rameterised contracts. The well-known production-cell example was partly specified in 
radl and the benefits of parameterised contracts were discussed in the context of this 
example. 

Our approach has been applied to industrial control automation, which increasingly 
relies on the international standard lEC 61131-3. This standard supports a component 
concept including hierarchical composition in terms of so-called Function Blocks and 
it defines a basic set of standardized function blocks. Control automation applications 
benefit from the possibility to can proven or calculated properties together with the code 
as they are typically built from library components. In addition, the certihcation of critical 
properties such as safety, reliability and timing is often a must [23]. Other classes of 
applications that may benefit from our protocol specifications include telecommunication 
applications [22] and contract-aware applications of distributed object technology. In 
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Beugnard’s four level model we are particularly addressing synchronisation level and 
quality of service level contracts [2] . 

The radl editor and DFSMs are currently implemented in Java. The core of the 
representation is a FSM class based on a number of auxiliary classes including hash 
library classes. It is used to represent the elements of a DFSM, i.e., its gates and its 
connecting abstract machines. 

For the future, it seems worthwhile to explore the use of parameterised contracts 
within a technique for compositional reasoning on global system properties in terms of 
local component properties. When considering an adapted component together with its 
environment as a component, we are able to describe the functionality of this higher- 
level component in terms of its constituent components. This prediction of properties 
of composed systems currently only works for layered systems. Since in practice many 
other composition pattern besides layered systems occur, future work is concerned with 
more general mechanisms to predict properties of the overall software architecture from 
properties of the single components and their interaction patterns. 



References 

1. R.J. Allen. A Formal Approach to Software Architecture. Ph.D. thesis. School of Computer 
Science, Carnegie Mellon University, Pittsburgh, PE, USA, May 1997. 

2. A. Beugnard, J.-M. Jezequel, N. Plouzeau, and D. Watkins. Making Components Contract 
Aware. IEEE Computer, 32(7):38-45, 1999. 

3. J. Bosch. Design and Use of Software Architectures - Adopting and evolving a product-line 
approach. Addison- Wesley, Reading, MA, USA, 2000. 

4. R.C. Cheung. A user-oriented software reliability model. IEEE Transactions on Software 
Engineering, 6(2):1 18-125, 1980. 

5. V. Diekert and G. Rosenberg (ed.) The book of traces. World Scientific Publ. Co., 1995. 

6. S. Frolund and J. Koistinen. Quality-of-service specification in distributed object systems. 
Technical Report HPL-98-159, Hewlett Packard, Software Technology Laboratory, 1998. 

7. D. Hamlet, D. Mason, and D. Woit. Theory of software reliability based on components. 
In Proceedings of the 23rd International Conference on Software Engeneering (ICSE-OI), 
361-370, IEEE Computer Society 2001. 

8. G. Hunzelmann. Generiemng von Protokollinformation fiir Softwarekomponenten- 
schnittstellen aus annotiertem Java-Code. Diplomarbeit, Fakultat fiir Informatik, Universitat 
Karlsruhe (TH), Germany, April 2001. 

9. G. Kiczales. Aspect-oriented programming. ACM Computing Surveys, 28(4): 154-154, 1996. 

10. C. Lewerentz and T. Lindner, editors. Formal Development of Reactive Systems - Case Study 
Production Cell. Number 891 in LNCS. Springer- Verlag, Berlin, Germany, 1995. 

11. D.C. Luckham, J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan, andW. Mann. Specification and 
analysis of system architecture using rapide. IEEE Transactions on Software Engineering, 
21(4):336-355, 1995. 

12. J. Magee, N. Dulay, S. Eisenbach, and J. Kramer. Specifying distributed software architec- 
tures. In Proceedings ofESEC ‘95 - 5th European Software Engineering Conference, volume 
989 of Lecture Notes in Computer Science, pages 137-153, Springer- Verlag, Berlin, 1995 

13. J. Magee and J. Kramer. Concurrency: State Models and Java Programs. Wiley & Sons, 
New York, NY, USA, 1999. 

14. N. Medvidovic and R.N. Taylor. A classification and comparison framework for software 
architecture description languages. IEEE Transactions on Software Engineering, 26(1):70- 
93, 2000. 




324 



Heinz W. Schmidt et al. 



15. B. Meyer. Object-Oriented Software Construction. Prentice Hall, Englewood Cliffs, NJ, 
USA, 2 edition, 1997. 

16. E. Ochmanski. Recognizable Trace Languages, in [5] 165-203 

17. l.H. Poernomo, R.H. Reussner, and H.-W. Schmidt. Architectures of Enterprise Systems: 
Modelling Transactional Contexts. In Proceedings of the First IFIP/ACM Working Conference 
on Component Deployment ( CD 2002 ), volume 2370 of Lecture Notes in Computer Science, 
233-243. Springer- Verlag, Berlin, 2002. 

18. R.H. Reussner. Parametrisierte Vertrdge zur Protokolladaption bei Software-Komponenten. 
Logos Verlag, Berlin, 2001. 

19. R.H. Reussner, H.-W. Schmidt, and l.H. Poernomo. Reliability prediction for component- 
based software architectures. Journal of Systems and Software, 66(3):241-253, Elsevier 
2003. 

20. H.-W. Schmidt. Compatibility of interoperable objects. In Bernd Kramer, Michael P. Pa- 
pazoglou, and Heinz W. Schnmidt, editors. Information Systems Interoperability, 143-181. 
Research Studies Press, Taunton, England, 1998. 

21. H.-W. Schmidt. Trustworthy components: Compositionality and prediction. Journal of Sys- 
tems and Software, 65(3):215-225, Elsevier 2003. 

22. H.-W. Schmidt and R.H. Reussner. Generating Adapters for Concurrent Component Protocol 
Synchronisation. In Proceedings of the 5th International Conference on Formal Methods for 
Open Object-based Distributed Systems, in B Jacobs and A Rensink (eds.), 213-229, Kluwer 
Academic Publisher, Massachusetts 2002 

23. N. Volker, B.J. Kramer. Automated verification of function block-based industrial control 
systems. Science of Computer Programming, Vol. 42, (1):101-113, Elsevier 2002 

24. W.-L. Wang, Y. Wu, and M.-H. Chen. An Architecture-Based Software Reliability Model. In 
Proceedings of the 1999 Pacific Rim International Symposium on Dependable Computing, 
December, Hong Kong, China. IEEE, 1999. 

25. B. Wydaeghe. Component Composition Based on Composition Patterns and Usage Scenarios. 
Dissertation, Department of Computer Science, Vrije Universitiet Brussel, 2001. 

26. D. Yellin and R. Strom. Protocol Specifications and Component Adaptors. ACM Transactions 
on Programming Languages and Systems, 19(2):292-333, 1997. 




From Object Orientation to Goal Orientation: 
A Paradigm Shift for Requirements Engineering 



Axel van Lamsweerde and Emmanuel Letier 



Departement d’Ingenierie Informatique 
Universite catholique de Louvain 
B-1348 Louvain-la-Neuve (Belgium) 
{avl,eletier}@info. ucl.ac.be 



Abstract. Requirements engineering (RE) is concerned with the elicitation of 
the objectives to be achieved by the system envisioned, the operationalization 
of such objectives into specifications of services and constraints, the assign- 
ment of responsibilities for the resulting requirements to agents such as hu- 
mans, devices and software, and the evolution of such requirements over time 
and across system families. Getting high-quality requirements is difficult and 
critical. Recent surveys have confirmed the growing recognition of RE as an 
area of primary concern in software engineering research and practice. 
The paper reviews the important limitations of OO modeling and formal speci- 
fication technology when applied to this early phase of the software lifecycle. It 
argues that goals are an essential abstraction for eliciting, elaborating, model- 
ing, specifying, analyzing, verifying, negotiating and documenting robust and 
conflict-free requirements. A safety injection system for a nuclear power plant 
is used as a running example to illustrate the key role of goals while engineer- 
ing requirements for high assurance systems. 

Keywords: Goal-oriented requirements engineering, high assurance systems, 
safety, specification building process, lightweight formal methods. 



1 Introduction 

The requirements problem has been with us for a long time. An early empirical study 
over a variety of software projects revealed that inadequate, inconsistent, incomplete, 
or ambiguous requirements are numerous and have a critical impact on the quality of 
the resulting software [Bel76]. Late correction of requirements errors was observed to 
be incredibly expensive [BoeSl]. A consensus has been growing that engineering 
high-quality requirements is difficult; as Brooks noted in his landmark paper on the 
essence and accidents of software engineering, “the hardest single part of building a 
software system is deciding precisely what to build” [Bro87]. In spite of such early 
recognition, the requirements problem is still with us - more than ever. Recent sur- 
veys over a wide variety of organizations and projects in the United States and in 
Europe have confirmed the problem on a much larger scale; poor requirements have 
consistently been recognized to be the major cause of software problems such as cost 
overrun, delayed delivery or failure to meet expectations [Sta95, ESI96]. The problem 
gets even more serious in the case of safety-critical or security-critical systems; most 
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severe failures have been recognized to be traceable back to defective specification of 
requirements [Lut93, Lev95, Kni02]. 

Semi-formal modeling notations a la UML and formal specification techniques 
have been proposed as candidate solutions to address the requirements problem. The 
strength of the former is their usability (at the price of fairly imprecise semantics), 
their support for multiple system views and their standardization. The strength of the 
latter is the wide variety of analysis tools they provide for algorithmic model check- 
ing, deductive verification, specification animation, specification-based testing, speci- 
fication reuse and specification refinement; as a result, the number of success stories 
in using formal specification technology for real systems is steadily growing from 
year to year [LamOOc]. 

In spite of such good news, traditional semi-formal modeling and formal specifica- 
tion techniques suffer from serious weaknesses that explain why they are not fully 
adequate for the upstream, critical phase of requirements elaboration and analysis. 

• Limited scope. The vast majority of techniques focus on the modeling and specifi- 
cation of the software alone. They lack support for reasoning about the composite 
system made of the software and its environment. Inadequate assumptions about 
the environment in which the software operates are however known to be respon- 
sible for many errors in requirements specifications [Jac95, Lev95]. Non- 
functional requirements are also generally left outside any kind of treatment. Such 
requirements form an important part of any specification; they are known to play a 
prominent role in the evaluation of alternatives, the management of conflicts, the 
derivation of architectures and evolution management [ChuOO, LamOOb, Lam03]. 

• Lack of rationale capture. Detailed requirements specifications are difficult to 
understand. Efforts have been made towards formal notations that are more read- 
able [Har87, Heim96, Heit96]. Such efforts however do not address the problem 
of understanding requirements in terms of their rationale with respect to some 
higher-level concerns in the application domain. 

• Poor guidance. The main emphasis in modeling and specification has been on 
suitable sets of notations and tools for a posteriori analysis. Constructive methods 
for building correct models/specifications for complex systems in a systematic, in- 
cremental way are by and large non-existent. The problem is not merely one of 
translating natural language statements into some semi-formal model and/or for- 
mal specification. Requirements engineering in general requires complex require- 
ments to be elicited, elaborated, structured, interrelated and negotiated. 

• Lack of support for exploration of alternatives. Requirements engineering is 
much concerned with the exploration of alternative system proposals in which 
more or less functionality is automated. Different assignment of responsibilities 
among software/environment components yield different software-environment 
boundaries and interactions. Traditional modeling and specification techniques do 
not allow such alternatives to be represented, explored, and compared for selec- 
tion. 

In this paper, we argue that goals offer the right kind of abstraction to address such 
inadequacies, notably, in the specific context of high assurance systems, that is, sys- 
tems for which compelling evidence is required that the system delivers its services in 
a manner that satisfies safety, security, fault-tolerance and survivability requirements 
[Lea95]. 
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Goals are declarative statements of intent to be achieved by the system under con- 
sideration [Dar93, LamOOb], The word “system” here refers to the software-to-be 
together with its environment [Fea87, Fic92]. Goals are formulated in terms of pre- 
scriptive assertions (as opposed to descriptive ones) [Zav97]; they may refer to func- 
tional or non-functional properties and range from high-level concerns (such as “safe 
nuclear power plant") to lower-level ones (such as “safety Injection overridden when block 
switch Is on and pressure Is less than ’Permit’). Agents are system components such as 
humans playing specific roles, devices and software. A requirement is a goal whose 
achievement is under responsibility of a single software agent. An expectation is a 
goal whose achievement is under responsibility of a single environment agent. 

Modeling and reasoning about goals is especially important for high assurance sys- 
tems as some of the system goals correspond to the application-specific safety, secu- 
rity, fault tolerance and survivability properties that need be achieved with high as- 
surance. Positive/negative interactions with the other system goals can be captured in 
goal models and managed appropriately [Lam98]; exceptional conditions in the envi- 
ronment that may prevent critical goals from being achieved can be identified and 
resolved to produce more robust requirements [LamOOa]; the goals can be specified 
precisely and refined incrementally into operational software specifications that 
provably assure the higher-level goals [Dar96, Let02a, Let02b]. Requirements in fact 
“implement” goals much the same way as programs implement design specifications. 

The paper discusses the relevance and benefits of explicitly modeling and reason- 
ing about goals at various levels of abstraction in the specific context of high assur- 
ance systems. We illustrate the use of a comprehensive set of goal-oriented tech- 
niques to build and analyze the requirements for a safety injection control system 
[Cou93]. Although fairly small, this case study comes from a real application, raises 
many of the issues found in high assurance systems and is frequently used to illustrate 
other methods such as, e.g., the SCR method [Heit96] and its analysis techniques 
[Bha99, Jef98, Gar99]. Other illustrations involving first-order formalizations can be 
found in [LamOOa, LamOOb, LetOl]. 



2 Goal- Oriented RE in Action: Elaborating Requirements 
for a Safety Injection System 

We follow our KAOS method to gradually derive operational requirements for the 
safety injection software from the underlying system goals. (KAOS stands for “Keep 
All Objectives Satisfied”). 

A goal refinement graph is elaborated first by identifying relevant goals from the 
preliminary system description [Cou93], typically by looking for intentional key- 
words in natural language statements and by asking why and how questions about 
such statements {goal elaboration step)', conceptual classes, attributes and associa- 
tions are derived from the goal specification {object modeling step)', agents are identi- 
fied together with their potential monitoring/control capabilities, and alternative as- 
signments of goals to agents are explored {agent modeling step)', operations and their 
domain pre- and postconditions are identified from the goal specifications, and 
strengthened pre-, post- and trigger conditions are derived so as to ensure the corre- 
sponding goals {operationalization step). In parallel, two other steps of the method 
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handle conflicting goals and obstacles that may obstruct goal satisfaction, respec- 
tively. The suggested ordering among steps corresponds to an idealized process; in 
practice however there is significant intertwining and backtracking between them. 

Our presentation will be succinct and fragmentary for space reasons; the interested 
reader may refer to [Let02c] for a full treatment of the case study. 



2.1 Goal Identification from the Source Document 

Fig. 1 shows some preliminary goals that have been directly identified from the first 
two paragraphs of the preliminary description of the safety injection system [Cou93]. 
This figure can be read as follows. One goal in a nuclear power plant is to maintain an 
effective coolant system (EffectiveCoolantSystem). This goal can be obstructed by an 
obstacle such as LossOfCoolant. (Obstacles may be seen as a high-level faults derived 
from goal negations; techniques for systematically identifying ways in which a sys- 
tem may fail will be discussed more precisely below.) 

The goal SafetyInjectionIffLossOfCoolant is introduced to mitigate the obstacle. This 
goal is then refined into 

• an accuracy property about the environment: LossOfCoolantIffLowWaterPressure, 

• the subgoal SafetyInjectionIffLowWaterPressure. 




Fig. 1. Preliminary goals identified from initial description of the safety injection system 
[Cou93] 



2.2 Formalizing Goals, Modeling Objects and Identifying State Variables 

Formal analysis techniques may complement informal or semi-formal ones in order to 
provide higher assurance in the correctness and completeness of the system require- 
ments. Goals then need to be formalized to enable their use. As we will see, goal for- 
malization also allows for more systematic guidance in the requirements elaboration 
process. 

In addition to the usual logical connectives, the following linear temporal operators 
will be used in this paper: 
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9 P 


P holds in some future state 




□ P 


P holds in all future states 




A=^C 


In every future state A implies C, i.e., D(A — 


^C) 


AoC 


In every future state A is equivalent to C, i.e., 


□ (A<r^C) 


• P 


P holds in the previous state 




@ P 


P has just become true, i.e., •— i P a P 





For example, the goal Maintain[SafetylnjectionlffLowWaterPressure] may be defined as 
follows: 

Goal Maintain [SafetyInjectionIffLowWaterPressure] 

InformalDef The safety injection signai shouid be ‘On’ when and oniy when the water pres- 
sure is below the ‘Low’ set point. 

FormalDef SafetyInjectionSignai = ‘On’ o WaterPressure < ‘Low’ 

The above goal refers to state variables WaterPressure and SafetyInjectionSignai that 
are declared as attributes of corresponding conceptual classes in a preliminary object 
model (see Fig. 2). 



CoolantSystem 


Regulated 


ESFAS 


WaterPressure: PressureUnit 


By 


SafetyInjectionSignai: {On, Off} 



Fig. 2. Goal-driven object modeling 



These attributes receive the following physical interpretation: 

WaterPressure: the actual pressure of water in the coolant system 

SafetyInjectionSignai: signal sent by the ESFAS (Engineered Safety Feature Actuation System) 
to safety features components to command the actual safety injection mechanisms 

Conceptual classes, attributes and associations are incrementally identified and de- 
fined as the requirements model is elaborated. When first-order formalizations are 
used, associations are typically derived from atomic formulas involved in the formal 
goal assertions [LamOOb]. As opposed to standard OO modeling where it is never 
clear how and why such or such class/attribute/association should enter the picture, 
goal-based object modeling is grounded on a precise criterion for identifying ele- 
ments of the object model, such elements are modelled when and only when they are 
involved in declarative assertions about goals and requirements. Also note the differ- 
ence with use-case driven modeling; here we start from higher-level, general, declara- 
tive and precise statements of intent rather than generally overspecific, operational 
and often imprecise descriptions of operations achieving goals left implicit. In fact, 
use cases can be trivially generated at the very last, operationalization step of our 
method (see Section 2.7). 
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2.3 Detecting and Resolving Goal-Level Conflicts 

Another goal appearing in the available source document is to avoid actuation of the 
safety injection system during normal start-up or cool down phases: 

Goal Avoid [SafetyInjectionDuringNormalStartUp/CoolDown] 

InformalDef Safety injection signais should not be sent during normal start-up or cool down. 
FormalDef (NormalStartUp v NormalCoolDown) => SafetyInjectionSignal = ‘Off’ 

This new goal introduces a conflict with the goal Maintain[SafetylnjecfionlffLowWater- 
Pressure] previously identified. This conflict is detected formally using a predefined 
conflict pattern from [Lam98]. The two goals are in fact not logically inconsistent; 
however, they become inconsistent when the plant is in start-up or cool down phase 
and the water pressure is below ‘Low’. This condition is called boundary condition for 
conflict [Lam98]; its formal definition is generated formally by instantiation of our 
formal conflict pattern which yields: 

0 ( (NormalStartUp v NormalCoolDown) a WaterPressure < ‘Low’) 

Conflict resolution tactics from [Lam98] may then be used to propose alternative 
resolutions; in this case, the conflict is resolved by weakening the goal Main- 
tain[SafetylnjectionlffLowWaterPressure] with the predicate appearing in the boundary 
condition. We thereby obtain: 

Goal Maintain [SafetyInjectionIffLowWaterPressureExceptDuringStartUp/CoolDown] 
InformalDef The safety injection signal should be ‘On’ whenever there is a loss of coolant, 
except during normal start-up or cool down. 

FormalDef SafetyInjectionSignal = ‘On’ <=> 

WaterPressure < ‘Low’ a -• (NormalStartUp v NormalCoolDown) 

This goal will be refined and operationalized in the following sections. 



2.4 Refining Goals and Identifying Agent Responsibilities 

Goals have to be refined until they can be assigned as responsibilities of single agents. 
However, a goal can be assigned to an agent only if this agent has sufficient monitor- 
ing and control capabilities to realize the goal [Let02a]. (Our terminology here is 
based on the 4-variable model [Par95] and the notion of shared phenomena [Jac95].) 

For example, the goal MaintainjSafetyInjectionIffLowWaterPressureExceptDuringStartUp/ 
CoolDown] is unrealizable by the ‘Engineered Safety Feature Actuation System’ 
(ESFAS) because this agent cannot monitor whether the plant is in normal startup or 
cooldown phase. 

A catalog of agent-based refinement tactics has been defined to guide the process 
of refining unrealizable goals until realizable subgoals are reached [Let02a]. Each 
tactic suggests the application of a formal refinement pattern (see Fig. 3). 
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/G [p(m)/q(im)n/q(''T^>’^P(n^)/ 



(accuracy goal on variable) (accuracy goal on predicate) 



Fig. 3. The ‘Introduce accuracy goal’ tactics 



The first tactic in Fig. 3 may be used to resolve ESFAS’ lack of monitorability of 
state variables NormalStartUp and NormalCoolDown. Applying the corresponding pattern 
yields a new, monitorable state variable. Overridden say, and a refinement of the unre- 
alizable goal Maintain[SafetylnjectionlffLowWaterPressureExceptDuringStartUp/CoolDown] 
into two subgoals: 

• a subgoal SafetylnjectionlffLowWaterPressureExceptWhenOverntfen, formally defined 
by 

SafetyInjectionSignal = ‘On’ « 

WaterPressure < 'Lov\/' a -i Overridden 

• a companion accuracy goal SafetylnjectionOvem'c/denDuringStartUp/CoolDown, for- 
mally defined by 

Overridden o (NormalStartUp v NormalCoolDown) 

Such formal definitions are generated by instantiation of the formal refinement pat- 
tern associated with the selected tactic. Goal refinement patterns are proved correct 
once for all [Dar96]; the STEP verification system [Man96] may be used to check 
that the conjunction of leaf nodes entails the parent node. At every pattern application 
the user gets an instantiated proof of correctness of the refinement for free. 

The above first subgoal SafetyInjectlonIffLowWaterPressureExceptWhenOvemden is 
now realizable by the ESFAS software agent because it is entirely defined in terms of 
variables that turn to be monitorable and controllable by this agent; the first subgoal 
therefore becomes a requirement on that agent. 

The accuracy subgoal SafetyInjectlonOvemdc/enDurIngStartUp/CoolDown is still not re- 
alizable by the ESFAS agent because this agent still lacks monitorability of state vari- 
ables NormalStartUp and NormalCoolDown. Agent-based refinement tactics may again be 
used to guide the generation of alternative refinements for this goal. One alternative 
consists in: 

(1) introducing two new variables. Block and Reset, that represent manual block and 
reset buttons controlled by a human Cperator agent; 

(2) assigning to the Cperator agent the responsibility of pushing the block button when 

and only when the plant enters normal cooldown/startup, and the responsibility of 
pushing the reset button when and only when the plant leaves normal cooldown/ 
startup (the latter two subgoals turn out to be realizable by the Cperator agent and 
therefore become environment assumptions)', and 
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(3) assigning to the ESFAS agent the responsibility of overriding safety injection if and 
only if ‘block’ is pushed, and the responsibility of enabling safety injection if and 
only if ‘reset’ is pushed (the latter two subgoals turn out to be realizable by the 
ESFAS software agent and therefore become software requirements). 

Further details about the generated goal graph and responsibility assignments may 
be found in [Let02c]. 

Note that both software requirements and environmental assumptions are in gen- 
eral needed to prove higher-level goals. 



2.5 Deriving Agent Interfaces 

Capturing the agents’ monitoring and control capabilities is an important aspect of the 
requirements elaboration process [Fea87, Par95, Jac95]. Such capabilities were gra- 
dually identified during the previous goal refinement step. The resulting agent inter- 
face model for the safety injection system is shown in Fig. 4. It corresponds to a con- 
text diagram [Jac95]. 



^ OperatorV 



Block 



Reset 



Safety Injection 

g ESFAS \ 



/ p-| Safety Feature 
Components 



WaterPressure 



Coolant System 



Fig. 4. Derived agent interface model for the safety injection system 

Note that alternative goal refinements and alternative responsibility assignments in 
general lead to alternative software-environment boundaries, that is, alternative sys- 
tem proposals and agent interfaces in which more or less is automated. 



2.6 Generating and Resolving Obstacles to Goal Achievement 

First-sketch specifications of goals, requirements and assumptions tend to be over- 
ideal; they are likely to be violated from time to time in the running system due to 
unexpected behavior of agents. The lack of anticipation of exceptional behaviors may 
result in unrealistic, unachievable and/or incomplete requirements. We capture such 
exceptional behaviors by formal assertions called obstacles to goal satisfaction. 

An obstacle O is said to obstruct a goal G iff 

{O, Dom} 1= —I Gobstruction 

Dom |=/= —1 Odomain consistency 

Obstacle analysis consists in taking a pessimistic view at the goals, requirements, 
and assumptions elaborated. The idea is to identify as many ways of breaking such 
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properties as possible in order to resolve them and produce more complete require- 
ments for more robust systems. 

We just illustrate a few results from obstacle analysis for some of the terminal 
goals we identified before. For example, in the previous goal refinement process, we 
made the following idealized assumption on the behavior of the Operator agent: 

Assumption Avoid[ManualBlockWhenNoStartUp/CoolDown] 

InformalDef The block button should not be pushed when the plant Is not entering normal 
startup or cool down. 

FormalDef @ (NormalStartUp v NormalCoolDown) => -• @ (Block = ‘Onj 

UnderResponsibilityOf Operator 

In this case, by just taking the negation of the above assumption we would identify 
the following obstacle: 

Obstacle OperatorPushesBIockWhenNotInStartUp/CoolDown 

InformalDef ‘Block’ is pushed when the plant is not entering normal startup or cool down. 

FormalDef 0 ( -, @ (NormalStartUp v NormalCoolDown) a @ (Block = ‘Onj) 

Similarly, from the assumption Achleve[ManualResetOnExitFromStartUp/CoolDown] as- 
signed to the Operator agent, we would identify the obstacle OperatorForgetsToReset. 
Other obstacles to assumptions on the Operator agent and to requirements on the 
ESFAS agent can be identified in the same way [Let02c]. 

Formal techniques for obstacle generation and refinement are detailed in 
[LamOOa]. The basic technique amounts to a precondition calculus that regresses goal 
negations backwards through known properties about the domain; formal obstruction 
patterns may be used as an alternative to shortcut formal derivations. A formal com- 
pleteness criterion is also given in [LamOOa]; such completeness is bound by the set 
of properties known about the domain. Our techniques allow the analyst to incremen- 
tally elicit new domain properties as well. 

Obstacles should be resolved once they have been generated. Obstacle resolution 
involves assessing the likelihood and criticality of the obstacle, investigating alterna- 
tive ways of resolving it, and choosing one resolution alternative based on various cri- 
teria such as cost, risks, performance, etc. 

Obstacle resolution tactics may be used to generate alternative resolutions 
[LamOOa]. For example, one of our tactics yields a resolution of the obstacle Operator- 
PushesBIockWhenNotlnStartUp/CoolDown in which an alternative refinement of the 
higher-level goal SafetyInjectlonOverrIddenDurIngStartUp/CoolDown is considered; in this 
alternative, the responsibility of the Operator agent is weakened, so as to partially 
cover the obstacle, whereas the responsibility of the ESFAS agent is strengthened. 
Such an alternative design might be identified by observing that pushing the block 
button when the water pressure is above some specified value ‘Permit’ is necessarily 
an Operator’s error because of a domain property stating that the plant cannot be in 
normal startup/ cooldown at such high pressure. Accordingly, the requirement on the 
ESFAS agent is strengthened so that safety injection does not become overridden if the 
block button is pushed when the water pressure is above ‘Permit’: 
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Goal Maintain [SafetylnjectionOverriddenWhenBlockSwitchOnAndPressureLessT/ianPerm/^ 

InformalDef Safety injection shouid become overridden when, and only when, the block 
switch is set to ‘On’ while the water pressure is less than ‘Permit’. 

FormalDef @ Overridden o 

@ (Block = ‘On’) A WaterPressure < ‘Permit’ a • -i Overridden 

UnderResponsibllityOf ESFAS 

The obstacle OperatorForgetsToReset is resolved in a similar way by weakening the 
responsibility of the Operator agent and strengthening the responsibility of the ESFAS 
agent. In this case, the requirement of the ESFAS agent is strengthened so that safety 
injection becomes automatically enabled when the water pressure raises above ‘Per- 
mit’. 

Our resolution tactics so far include goal substitution, agent substitution, goal 
weakening, goal restoration, obstacle prevention and obstacle mitigation [LamOOa]. In 
general several generated resolutions will be applicable so that a “best” alternative 
needs to selected according to non-functional goals from the goal graph (we come 
back to this below). The selection and application of a resolution may be carried out 
at specification time, to produce more robust requirements specifications, or at run 
time, when a requirements monitor detects that the obstacle does occur or is likely to 
occur [Fea98]. 

Note that obstacle analysis is an iterative process; it may produce new goals for 
which new obstacles may need to be identified. In the resulting software specifica- 
tion, some of the obstacles may be totally or partially resolved, some obstacles may 
remain unchanged (e.g., if they are highly unlikely, do not matter or are deferred to 
run time) and some new obstacles may appear as a result of previous resolutions. 

As mentioned before, the selection among alternative resolutions and the decision 
to iterate further obstacle analysis cycles should be based on some trade-off assess- 
ment among various non-functional, application-specific goals about safety, security, 
cost, performance, etc. This is an area where much work remains to be done. Qualita- 
tive techniques might help here by exposing the competing influences of various 
alternatives with respect to non-functional goals. A preliminary proposal can be found 
in [ChuOO] where a procedure is proposed for propagating positive/negative influ- 
ences along alternative paths in the goal graph. For high assurance systems, however, 
more accurate, quantitative techniques are required. For example, probabilistic risk 
assessment techniques might provide more precise input to the decision making proc- 
ess. Such techniques, however, rely on the availability of accurate estimates of prob- 
abilities of failure events. Obtaining such data may be problematic; the use of such 
quantitative techniques has therefore been controversial [Lev95]. The real challenge 
is probably to define a decision process that combines qualitative reasoning for those 
non-functional aspects of the system for which no accurate quantitative weighting can 
be made and quantitative reasoning for those non-functional aspects for which mean- 
ingful weighting can be obtained. 

Obstacle analysis may be seen as a goal-oriented, formal, constructive method for 
building fault trees and recovery actions. It is particularly relevant to high assurance 
systems as many problems and failures of such systems are known to be caused by 
poor designs that are unable to cope with errors caused by humans, devices and soft- 
ware [Lev95]. 
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2.7 Deriving Operational Requirements from System Goals 

The next step of the requirements elaboration process consists in deriving operational 
software specifications from the terminal goals assigned to software agents. The re- 
sult is an operation model that defines the various services to be provided by the 
software in terms of their pre-/postcondition in the domain and strengthened condi- 
tions ensuring that the underlying goals in the goal model are met by the services. 

A catalog of formal operationalization patterns is available to support the opera- 
tionalization step [Let02b]. For example, the ‘Immediate Achieve’ pattern is shown in 
Fig. 5. 



Let us come back to the goal 

Maintain [SafetylnjectionOverriddenWhenBlockSwitchOnAndPressure/-ess7/7anPemt/t] 

that we assigned to the ESFAS agent, and to the right-to-left implication in the formal 
definition of this goal given in Section 2.6. The ‘Immediate Achieve’ operationalization 
pattern can be used to derive the following operational requirements: 

Operation OverrideSafetyInjection 

PerformedBy ESFAS 

Input Block, WaterPressure; Output Overridden 
DomPre -i Overridden 
DomPost Overridden 

ReqPre/Trig For SafetyInjectionOverriddenWhenBlockSwitchOn 



@ (Block = ‘On’) A WaterPressure < ‘Permit’ 

Note that a distinction is made between domain pre- and postconditions that cap- 
ture what any application of the operation means in the application domain, and re- 
quired pre-, trigger, and postconditions that capture requirements on the operations 
that are necessary to achieve the goals. (Such distinction somewhat corresponds to the 
distinction between indicative and optative properties in [Jac95, Zav97].) 

In the above operation, the ReqPrefTrigger keyword is a syntactic shortcut to express 
that the condition is both a required pre- and a required trigger- condition for the 
satisfaction of the corresponding goal; the operation may be applied only if the condi- 




Fig. 5. The ‘Inmediate Achieve’ pattern 



AndPressureLessThanPermit: 
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tion is true and must be applied if the condition becomes true and the domain precon- 
dition is true. 

Similarly, from the goal Maintain[SafetylnjectionEnabledWhenPressureAbovePermitOr- 
Manual Reset], we can systematically derive the need for an operation EnableSafety- 
Injection together with strengthened conditions on this operation that will guarantee the 
satisfaction of this goal. Specifications for the operations SendSafetyInjectionSignal and 
StopSafetyInjectionSignal are similarly derived from the specification of the goal Main- 
tain[Safetyln]ectionWhenLowWaterPressureAndNotOverridden], see [Let02c] for details. 

It is worth noting that our goal-oriented requirements elaboration process ends 
where most traditional specification techniques would start. For example, the opera- 
tional specifications obtained above can be mapped to SCR tables for the same sys- 
tem through a series of transformation steps each of which resolves a semantic, struc- 
tural or syntactic difference between the source (KAOS) specification and the target 
(SCR) one [Del03]. 

Note again the difference with use-case driven modeling; we started from higher- 
level, general, declarative and precise statements of intent rather than generally over- 
specific, operational and often imprecise descriptions of operations achieving goals 
left implicit. Use cases emerge at the last step of our method as aggregations of the 
operations that operationalize functional goals assigned to software agents. 



3 Conclusion 

We used a safety injection system as a running example to illustrate the benefits of a 

constructive, goal-oriented approach to requirements elaboration and analysis. The 

key points illustrated by this elaboration process are the following. 

• Goal-oriented modeling and specification takes a wider system engineering per- 
spective; goals are prescriptive assertions that should hold in the system made of 
the software-to-be and its environment; domain properties and expectations about 
the environment are explicitly captured during the requirements elaboration pro- 
cess, in addition to the usual software requirements specifications. 

• Operational requirements are derived incrementally from the higher-level system 
goals they “implement”. 

• Goals provide the rationale for the requirements that operationalize them and, in 
addition, a correctness criterion for requirements completeness and pertinence 
[Yue87]. 

• Obstacle analysis helps producing much more robust systems by systematically 
generating (a) potential ways in which the system might fail to meet its goals and 
(b) alternative ways of resolving such problems early enough during the require- 
ments elaboration and negotiation phase. 

• Alternative system proposals are explored through alternative goal refinements, 
responsibility assignments, obstacle resolutions and conflict resolutions. 
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• The goal refinement structure provides a rich way of structuring and documenting 
the entire requirements document. 

• A multiparadigm, ‘multi-button’ framework allows one to combine different levels 
of expression and reasoning: semi-formal for modeling and structuring, qualitative 
for selection among alternatives, and formal, when needed, for more accurate rea- 
soning. 

• Goal formalization allows RE-specific types of analysis to be carried out, such as 

- guiding the goal refinement process and the systematic identification of objects 
and agents [LamOOb, Let02a]; 

- checking the correctness of goal refinements and detecting missing goals and im- 
plicit assumptions [Dar96]; 

- guiding the identification of obstacles and their resolutions [LamOOa]; 

- guiding the identification of conflicts and their resolutions[Lam98]; 

- guiding the identification and specification of operational requirements that sat- 
isfy the goals [Dar93, Let02b]. 

Several important topics are however not yet sufficiently addressed by current 
goal-oriented techniques. 

• Current support for the evaluation and selection among multiple alternatives ex- 
plored during the requirements elaboration process is highly limited. As discussed 
before, a blend of qualitative and quantitative reasoning techniques should be de- 
vised for more accurate evaluation of alternatives in terms of measurable quanti- 
ties. Such techniques should probably be based on specific models for specific 
types of non-functional goals, e.g., risk models for safety goals, cost models for 
cost-related goals, performance models for performance-related goals, etc. 

• Much work also remains to be done to provide specialized techniques for goal 
refinement and obstacle/conflict analysis that are targeted to specific goal catego- 
ries relevant to high assurance systems (e.g., safety or security) and to specific 
domains (e.g., air traffic control, medical applications). This means characterizing 
and refining goal categories more thoroughly (maybe in domain- specific terms at 
some point), defining suitable notations and techniques for modeling and specify- 
ing properties in each category, and finding systematic ways of reasoning about 
their positive/negative interactions at the goal level. 

• Further work is also needed to integrate the methodological support provided by 
our goal-oriented requirements engineering method with existing specification 
analysis tools. Such integration may occur at two levels. First, we would like to 
use existing tools to automate some of the RE-specific formal reasoning described 
above. For example, we recently built a tool prototype for early model checking of 
goal models; the generated counter-examples suggest inconsistent or missing 
goals. Second, we would like to map the result of goal-oriented requirements elab- 
orations to specialized tools for formal analysis of operational specifications. For 
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example, we did a mapping of KAOS models to SCR tables [Del03]. Other map- 
pings, e.g., to the NuSMV model checker (http://nusmv.irst.itc.it/) or the Alloy 
analyzer (http://sdg.lcs.mit.edu/alloy/), are under way. 
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Abstract. An algebraic approach to the view consistency problem in software 
development is provided. A view is formalised as a sentence of a viewpoint lan- 
guage; a viewpoint is given by a language and its semantics. Views in possibly 
different viewpoints are compared over a common view for consistency by a het- 
erogenous pull-back construction. This general notion of view consistency is il- 
lustrated by several examples from viewpoints used in object-oriented software 
development. 



1 Introduction 

The use of views in software development supports an often desirable “separation of 
concerns”. Each stakeholder of a software system may express his view of the sys- 
tem from his own viewpoint and may employ the notation most appropriate for this 
viewpoint. In particular, most viewpoints taken by system stakeholders concentrate on 
parts of the whole system under construction which may either be rather orthogonal 
and separated by clean interfaces, or may overlap in intricate ways. However, the use of 
different views in software development poses the problem to ensure consistency, i.e., 
to guarantee that there is an overall integration of the views that is implementable in a 
software product. On the one hand, this means to integrate partial descriptions of the 
system; on the other hand, different notations and their semantics have to be compared. 

The “system-model” solution to the view consistency problem embeds all view- 
points used for software development in a single, unifying system model and com- 
pares the embedded views over the system model’s semantics. This approach has been 
put forward, for example, by stream-based [6], graph grammar [7] and rewrite system 
models [13], or the integration of different specification formalisms, like CSP and Z [8, 
19] or a combination of algebraic specifications and labelled transition systems [12, 
16]. However, an encompassing single system model renders reasoning on different 
views in a formalism suitably adapted to the view’s viewpoint rather difficult. The 
“heterogeneous-specification” line of research concentrates on the comparison and in- 
tegration of different, heterogeneous specification formalisms, retaining the formalisms 
most appropriate for expressing parts of the overall problem. Most prominently, insti- 
tutions [9] and general logics [11] are used as a formal basis establishing a powerful 
framework for heterogenous specifications and heterogenous proofs [2, 15, 14]. These 
investigations, which concentrate on formal, logic-based software development, is com- 
plemented by set-based frameworks for view comparison and integration [3, 5]. 

* This research has been partially sponsored by the DFG project WI 841/6-1 “InOpSys”. 

M. Wirsing et al. (Eds.): RISSEF 2002, LNCS 2941, pp. 341-357, 2004. 
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Our approach to the view consistency and integration problem in software devel- 
opment follows the “heterogeneous specification” approach, but applies these ideas to 
general software development. A viewpoint is given by a language and its semantics; a 
view in a viewpoint is a sentence of the viewpoint’s language. We introduce a suitable 
notion of translations between viewpoints and view consistency for views in different 
viewpoints. We also define a general notion of consistency of views in possibly differ- 
ent viewpoints over a common view in maybe yet another viewpoint using a heteroge- 
nous pull-back construction. In particular, this construction avoids the unification of all 
different viewpoints into a single, formal system model. We illustrate our notion of con- 
sistency by several examples for viewpoints used in common object-oriented software 
development such as class diagrams and state machine diagrams. 

The remainder of this paper is structured as follows: Sect. 2 motivates the use of 
multiple views and the consistency problem by means of examples. Sect. 3 introduces 
our algebraic notion of viewpoints and views. The translation of viewpoints and views is 
defined in Sect. 4. The algebraic notion of view consistency is presented in Sect. 5. We 
conclude by an outlook to further research topics. The appendices contain the formal 
definitions for the viewpoints used in the examples. 



2 Multiple Views 

In software development, multiple views and viewpoints are ubiquitous. As a simple ex- 
ample, consider the description of the interaction of an automatic teller machine (ATM) 
with a bank in Fig. 1. Using the “Unified Modeling Language” (UML [4]), the static 
structure of such a system may be specified by a UML class diagram as in Fig. 1(a). 
The dynamic behaviour of instances of the classes ATM and Bank may be given by state 
machine diagrams, see Fig. 1(d) for an ATM, Fig. 1(e) for a Bank. Finally, collaboration 
diagrams may be used for specifying desired (cf. Fig. 1(b)) or undesired behaviours (cf. 
Fig. 1(c)) of interaction. 

These views overlap and thus must be checked for consistency in several ways: First 
of all, the static structure and both of the state machines can be considered consistent if 
the state machines refer only to attributes, association ends, operations, and receptions 
that are declared in the class diagram. This syntactical notion of consistency amounts to 
extracting a class diagram from the state machines and checking whether this extracted 
class diagram is contained in the given class diagram of the static structure. In the same 
way, the collaboration diagrams can be checked for their class-diagram compatibility 
and, moreover, the same signature check must be applied to the collaborations and the 
state machines. Thus, when comparing the diagrams from a class-diagram or signature 
viewpoint, there must be translations from the views and their viewpoints under com- 
parison into the signature viewpoint where consistency checking is signature inclusion. 
The same technique of consistency checking applies for showing that a collaboration is 
indeed realised by interacting state machines. As a collaboration specifies possible mes- 
sage exchanges and their order, the message exchanges of the interacting state machines 
have to be compared to these possible partial orders of message exchanges for inclu- 
sion. Hence, comparing diagrams from an interaction viewpoint involves translations 
from the views and their viewpoints under comparison into the interaction viewpoint 
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ATM 


atm bank 


Bank 


«signal» PINVerified 
«signal» reenterPIN 
«signal» abort 


1 1 


boolean cardValid = true 
int numincorrect = 0 
int maxNumIncorrect = 2 


verifyPINQ 
«signal» done 



(a) Class diagram 



1:verifyPIN() 1 : verifyPIN() 

3: verifyPINO 3: verifyPIN() 




2: reenterPIN 
4: PINVerified 



2: abort 
4: PINVerified 



(b) Expected collaboration 



(c) Erroneous collaboration 




[numincorrect < maxNumIncorrect] 




(e) State machine diagram for class Bank 
Fig. 1. Multiple views in a UML model of an ATM. 
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context Account :: deposit (n : int) 
post: bal = bal@pre+n 



(a) Client view 

context Account :: deposit (n : int) 
post: if count < treshoid ( ) 

then count = count@pre+l and 
bai = bai@pre+n 
else count = 0 and 

bai = bai@pre+n+bonus ( ) 

(b) Management view 

Fig. 2. Multiple views in UML models of a bank account. 



Account 

bal : int 
count : int 
deposit(n : int) 
withdraw(n : int) 
bonusO : int 
treshoidQ : int 



Account 

bal : int 
deposit(n : int) 
withdraw(n : int) 



where consistency checking is partial order inclusion. Similarly, the interaction view- 
point can be used to check that message exchanges given by a collaboration diagram 
are not inclnded in the message exchanges of interacting state machines. 

An analogous approach applies when a system is viewed from different angles by 
different stakeholders. Consider the (over-simplified) descriptions of a bank acconnt 
depicted in Fig. 2, using UML and the “Object Constraint Language” (OCL [18]) as a 
pre-/postcondition language: A client may take the straightforward view of an account 
represented in Fig. 2(a), whereas the management of the bank may want to apply a 
special bonus rule for frequent customers thus taking the view in Fig. 2(b). 

As in the previous example, several viewpoints are employed in both descriptions. 
From the structural viewpoint, UML class diagrams are used for specifying the static 
structure of a system, from the behavioural viewpoint the desired behaviour is expressed 
in terms of OCL pre-/postconditions on operations. Thus, taking the views as heteroge- 
nous views combined from views in the structnral and the behavioural viewpoint, both 
the management and the client view can be checked for internal consistency. Further- 
more, the views in the structural viewpoint may be considered to be consistent as the 
structural view in the management view simply extends the structural view in the client 
view. However, the behavioural views of the client and the management on the be- 
haviour of the operation Account : : deposit are inconsistent, as the client specification 
does not take into account the bonus feature of the management view. 



3 Viewpoints and Views 

Generalising from the examples above, a viewpoint of software development consists 
of a syntactic domain, a semantic domain, and a mapping from the syntax into the 
semantics. The syntactic domain captures the viewpoint notation, most conveniently in 
terms of an abstract syntax. A sentence of this abstract syntax conveys the information 
expressed in a view according to the viewpoint’s notation. The semantic domain defines 
appropriate models for the abstract syntax. 
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More concretely, a viewpoint 'f is represented by a formal language category L, 
a semantic domain category D, and a semantic functor Mod : ^ D. K view in a 

viewpoint y = (L, D, Mod) is a specification object V in the formal language category 
L; its semantics, i.e. its models, is given by Mod(y) € D. Note that we choose the 
opposite language category L°p for the semantics in order to express the well-known 
contravariance of syntax and semantics in logic and model-theory [1]. 

Example 3.1. The structural viewpoint Struct, cf. Fig. 1(a) and the class diagrams in 
Fig. 2(a) and 2(b) for concrete examples and App. B.l for a detailed definition, uses 
the language StructDiag of structure or class diagrams, comprising classes with typed 
attribute and method signatures and the (binary) associations between classes. As the 
semantic domain StructAlg the class of many-sorted algebras over the many-sorted 
algebraic signatures induced from structure diagrams is employed. The signature of a 
structure diagram consists of sorts from the classes and operations from the attributes, 
methods, and associations. The model functor Modstmct maps a structure diagram to 
the algebras over its induced signature. 

Example 3.2. The behavioural viewpoint Beh, cf. Fig. 2(a) and 2(b) for concrete ex- 
amples and App. B.2 for a detailed dehnition, uses the language BehSpec of pre-/ 
postconditions for annotating methods of classes. As the semantic domain BehAlg the 
class of many-sorted algebras over the many-sorted algebraic signature induced from 
pre-/postcondition annotations is employed. The signature of pre-/postconditions con- 
sists of sorts for the classes and operations from the attributes and associations. The 
model functor Mod Beh maps a pre-/postcondition specification to the algebras over its 
induced signature such that the methods applied to a state satisfy the pre-/postconditions. 

Example 3.3. The instance viewpoint Inst, cf. App. B.3 for a detailed definition, uses 
the language InstDiag of object diagrams, comprising typed objects with typed slots 
and their values and (binary) links between objects. As the semantic domain InstAlg the 
class of many-sorted algebras over the many-sorted algebraic signatures induced from 
object diagrams is employed. The signature of an object diagram consists of sorts for 
the types of the objects, operations from the attributes and links, and constant operations 
for the objects. The model functor Mod/„st maps an object diagram to the algebras over 
its induced signature such that the valuations of the slots and the links are satisfied. 

Example 3.4. The interaction viewpoint Inter, cf. Fig. 1(b) and 1(c) for concrete ex- 
amples and App. B.4 for a detailed definition, uses the language InterDiag of collabo- 
ration diagrams, comprising objects and a partial order of message exchanges between 
these objects. As the semantic domain InterAlg the class of algebras representing par- 
tial orders of messages between objects is employed. The model functor Mod/„ter maps 
a collaboration diagram to the class of partial orders of messages between objects that 
contain at least the partial order of message exchanges specified in the collaboration. 

Example 3.5. The machine viewpoint Mach, cf. Fig. 1(d) and 1(e) for concrete exam- 
ples and App. B.5 for a detailed definition, uses the language MachDiag of state ma- 
chine diagrams, comprising classes with their attributes and methods, and a mapping 
of classes to state machines. Each state machine is given by a set of states, an initial 
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State, and a set of transitions. Each transition is annotated with an event accepted by 
the transition, its effects and messages that are sent when the transition is taken. As the 
semantic domain MachAlg the class of algebras representing the possible transitions 
of the state machines is employed. The model functor ModMac/i maps a state machine 
diagram to the class of algebras with transitions for the machines in the diagram. 

4 Translation 

Viewpoints and thus views may be related by translations: Certain information of a 
view can be extracted and reformulated in another viewpoint. Translations may well in- 
duce partial loss of information, as not all viewpoints carry comparable data and not all 
viewpoints allow the specifier to express a software design at the same level of detail. 
In particular, translation may not always be possible syntactically. However, whenever 
information is shared between viewpoints, such as information on types in the struc- 
tural, instance, interaction, and machine viewpoints, translations afford the necessary 
extraction mechanism. 

A translation transfers information from one viewpoint = (Li, Di, Modi) into 
another viewpoint T 2 = (L 2 , ^ 2 , Mod 2 ). A syntactic viewpoint translation r from 
to 1^2 uses viewpoint notations: t : Li ^ L 2 - Corresponding to the contravariant 
behaviour of the model functors, a semantic viewpoint translation fi from T) ^ T 2 
operates contravariantly on the semantic domains of the viewpoints: fx : D 2 ^ Di. 
A viewpoint translation from Ti to T 2 consists of a pair of syntactic and semantic 
viewpoint translations (t, p) : T) ^ T 2 . 

Example 4.1. We consider the translation of the instance viewpoint Inst into the struc- 
tural viewpoint Struct. Syntactically, a class diagram can be induced from an object 
diagram by turning type names, slots, links, and links ends into classes, attributes, as- 
sociations, and association ends. Thus we have a syntactic viewpoint translation t : 
InstDiag — > StructDiag. As an algebra in StructAlg always can be interpreted as 
an algebra in InstAlg by forgetting the methods, we also have a semantic viewpoint 
translation p : StructAlg InstAlg. 

Example 4.2. There is also a syntactical translation of the structural viewpoint Struct 
into the instance viewpoint Inst: t : StructDiag — s- InstDiag can be trivially defined 
by translating each structure diagram into the empty object diagram. However, there 
is a more natural semantic translation from the structural viewpoint into the instance 
viewpoint p : InstAlg StructAlg by forgetting the additional object constants. 

Example 4.3. In a similar way to translating the instance viewpoint into the structural 
viewpoint, there is a syntactical translation r : InstDiag — *■ InterDiag of the instance 
viewpoint Inst into the interaction viewpoint Inter: The objects are kept, but the in- 
teraction diagram will contain no messages. Conversely, the interaction viewpoint can 
be translated syntactically into the instance viewpoint, r : InterDiag InstDiag, by 
keeping the objects and adding links between objects which exchange messages. 

Example 4.4. The examples 4.1 and 4.3 can be combined into a syntactic translation 
T : Inter — > Struct which infers the classes and associations from the interaction 
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diagram. However, there is also a direct syntactic translation from Inter to Struct that 
also keeps the messages. 

Example 4 . 5 . A syntactic translation of the interaction viewpoint into the machine view- 
point can be achieved as follows: Each class of an object in the interaction is associated 
with a machine that accepts the messages incoming to the object. An incoming mes- 
sage is answered by all following outgoing messages [ 10 ]. This syntactic translation is 
complemented by a a semantic translation of the interaction viewpoint Inter into the 
machine viewpoint Mach, i.e. p : MachAlg — s- InterAlg. The machines in a machine 
algebra are run concurrently from their initial states. Each machine that fires a transition 
sends messages to the other machines. The receiving machine reacts to the incoming 
event by subsequently firing a transition. Thus, every run of the machines induces a 
partial order of exchanged messages. 

5 Consistency 

Given the notions of viewpoints, views, and viewpoint translations introduced above, 
the view consistency problem in software development amounts to relating views in 
different viewpoints by syntactical or semantical translations, and checking whether the 
overlapping parts of the views are acceptable to the software engineers. In particular, 
views may be consistent from certain viewpoints, but deemed to be inconsistent from 
others. Therefore it seems advisable to introduce a point of comparison between two 
views. This point of comparison can be chosen as a view in the viewpoint from one 
of the views to be related, or may be of yet another viewpoint. Moreover, the point 
of comparison view can specify the minimal requirements for the compared views or 
can embrace all the information, relative to the chosen viewpoint, that is expected to 
be available in the views to be compared. Finally, views can be compared syntactically 
involving syntactic translations, or semantically using semantic translations. 

5.1 Syntactic Consistency 

The syntactic consistency check for two views over a common point of comparison 
view necessitates the syntactic translation of the views under comparison into the view- 
point of the point of comparison. We call two views consistent over a common view 
if there are embeddings of the common view in the translated versions of the views 
under comparison. More precisely, when comparing the views Vi and V2 in viewpoints 
yi = {Li, Di, Modi) and Y2 = (T2, D2, Mod2), respectively, over a point of com- 
parison view V in a viewpoint ^ = (L, 17 , Mod) we require that there are syntactic 
viewpoint translations ti : y ^ 'f'l, T2 : 'f' ^ 'f'2 from the viewpoint 'E. Given these 
translations there must be embeddings li : V ^ d(Ti) and t2 : V — > T2(V2). If 17 
admits push-outs, we obtain the following diagram: 
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Here, the point of comparison view V is shared between the (translated) views Vi 
and V 2 , that is, V contains symbols that should have the same meaning in Vi and V 2 . 

Example 5.1. Considering the structure diagram S from Fig. 2(b) and the behavioural 
specihcations B\ and B 2 in Fig. 2(a) and Fig. 2(b), syntactic consistency of B\ and 
B 2 over S can be seen from the translations of behavioural specihcations into struc- 
ture diagrams: The additional pre-/postconditions are forgotten, thus the push-out in 
StructDiag is isomorphic to S. Note that a comparison of B\ and B 2 over the struc- 
ture diagram from Fig. 2(a) would result in an enrich structure diagram also containing 
bonus and threshold. 

In general two behavioural specihcations B\ and B 2 are consistent over a struc- 
ture diagram S if, and only if all classes, attribute signatures, operation signatures, and 
association end signatures of S are contained in both behavioural specihcations. The 
push-out constructs the union of all features of B\ and B 2 separately renaming the 
features in Bi and B 2 that are not present in S. 

As the example illustrates it may sometimes be desirable to require that the point 
of comparison already contains all information that can be deduced from the views un- 
der comparison by translating these views into the common viewpoint. Such a point 
of comparison view is called embracing and leeds to a similar consistency diagram as 
for the shared case, but with arrows reversed such that C now becomes a pull-back in D: 



Example 5.2. We consider the comparison of the collaboration views I\ and I 2 in 
Fig. 1(b) and Fig. 1(c) over the embracing point of comparison view S in Fig. 1(a). 
Translating /i and I 2 into structure diagrams, there are embeddings of these translated 
interaction diagrams into S. Therefore Ii and I 2 are syntactically consistent with re- 
spect to S. The pull back contains only the classes ATM and Bank with their respective 
methods PINVerified and verifyPIN. 

5.2 Semantic Consistency 

The semantic consistency check for two views over a comparison view involves the 
construction of a common model such that the comparison view is extended by the 
compared views consistently. The construction is dual to syntactic consistency. How- 
ever, the existence of embeddings is sufficient to assess whether views are consistent 
or not, as embeddings may also exist for semantically inconsistent views. We there- 
fore have to inspect the pull-back, i.e., roughly speaking, the intersection, of the model 
classes of the views. If the pull-back is empty, then the views are inconsistent; if it is 
not empty, the views are formally consistent, but the feature interaction of the views 
may still result in undesired behaviour which can be revealed by inspecting the models 
of the pull-back. 
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More specifically, let Vi and V2 be views in the viewpoints = (Li, I 9 i, Modi) 
and ^2 = (^2, -D2,Mod2), respectively, and let 1 ^ be a (shared) point of comparison 
view in viewpoint = (L,Z 9 , Mod). We say that Vi and V2 are semantically con- 
sistent with respect to V , if there are semantic viewpoint translations fXi \ ^ Y, 

1^2 '■ Y2 ^ Y from the viewpoint Y and there exists a pull-back C in 19 such that the 
following diagram commutes: 




Note that again the common view provides the viewpoint of the integrating model. 
The commutation of the diagram above implies that is a shared view between Vi 
and V2. The opposite case, that V embraces all information that can be extracted by 
viewpoint translations from Vi and V2 leads to a diagram where the embedding arrows 
between V{ and V, and V2 and V have to be reversed. 



Example 5 . 3 . The semantical consistency of the behavioural specifications B\ and B2 
in Fig. 2 (a) and Fig. 2 (b) over the structure diagram S from Fig. 2 (b) can be checked 
as follows: The models of B\ are Siggg^(i?i) = ({Account, int, State}, {bal : State x 
Account — > int, . . . })-algebras subject to the behavioural specification post: bal 
= bal@pre-i-n, the models of B2 are Sig5g/,(Si)-algebras subject to the behavioural 
specification post : if count < threshold ( ) ... endif . But the models of Bi and 
B2 in the behavioural viewpoint Beh can be translated into models in the structural 
viewpoint Struct forgetting the additional sorts and operations. These translated models 
can be trivially embedded in Mod(S') = Sig^j^^gt {S)-Alg. The pull-back in StructAlg 
turns out to be the category of algebras over the amalgamated sum of the signatures 
of Bi and B2 over the signature of S where all symbols from S are shared. In partic- 
ular, the pull-back is not empty and thus Bi and B2 are semantically consistent over 
S. However, this formal consistency may be misleading as bonus'^ is identically 0 for 
A G \C\ or counF^(s, a) threshold^(s, a) for all s G State^, a G Account'^; this 
may not be desirable. Moreover, if a software designer requires bonus to be greater than 
zero, the views become inconsistent. 

More generally, in the case of behavioural specifications the semantic consistency, 
i.e. the calculation of pull-backs, can be reduced to logical consistency by computing 
the conjunction of the theories of the views under consideration (modulo renamings 
required by the shared view). 



Example 5 . 4 . A comparison of the machine view A with the state machines in Fig. 1 (d) 
and 1 (e) with the interaction view I of the collaboration in Fig. 1 (b) leaves several pos- 
siblities for choosing a common point of comparison view. We employ the empty inter- 
action view 0 as the shared view. The translation of M.odMach{A) into the interaction 
viewpoint amounts to all possible interaction sequences of the state machines. The pull- 
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back C now contains all partial orders of message exchanges that are part of the partial 
orders in Mod/„ter(f) and the partial orders from the translation of ModMac/i(^)- 

In general, an interaction diagram is consistent with a machine diagram w. r. t. the 
empty interaction diagram if there is a run of the collaboration diagram that is also a 
run of the state machines. In the case of hnite state systems, like the ATM example, this 
property can he checked efficiently by model checking [17]. 

6 Conclusions 

We have presented an algebraic framework for view consistency in software develop- 
ment. The framework is inspired by the institution-based approaches to heterogeneous 
specihcations. Viewpoints are formalised as a pair of a syntactic and a semantic cate- 
gory linked by a model functor. Views are objects in the syntactic category. Consistency 
of views is dehned by a heterogeneous pullback construction. 

However, view consistency is merely a stepping stone to the successful employment 
of different views in software development. Views on a system will evolve over the 
software life-cycle, some may extend over all software development phases, some may 
be replaced, refined, or be combined during construction. Taking views and viewpoints 
serious hence in particular means to provide further support for separation of concerns 
by view maintainance allowing the different stakeholders to keep their viewpoints of the 
system. Correct view development, replacement, and rehnement remain a challenge. 
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A Many- Sorted Algebras 

Signatures. A (many-sorted) signature {S, F) consists of a set of sort symbols S and 
a set of operations F of the form / : (si)i<i<fc ^ sq (k G N) with / an operation 
symbol and sqi si, . . . , Sfc € S. We require all sort symbols and all operation symbols 
to be distinct. 

A signature morphism a : {S, F) — s- {S', F') is given by a map a from the symbols 
of {S, F) to the symbols of {S' , F') such that a sort symbol is mapped to a sort symbol 
and an operation symbol is mapped to an operation symbol; and the following condition 
holds: Given an operation / : (si)i<*<fc ^ sq G F the image a{f) : {a{si))i<i<k 
ct{so) is in F' . 

The category Sig has as objects: signatures, and as morphisms: signature mor- 
phisms. The composition of signature morphisms is defined as function composition; 
the identity morphism on a signature is given by the identity on the signature’s symbols. 

Algebras. Given a (many-sorted) signature S = {S,F), a (many-sorted) E-algebra A 
consists of a family of universes {s^)s^s and a family of functions (/^) /g f such that 
: (sf )i<*<n ^ for / : (si)i<^<„ ^ Sq G F. 
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A S-algebra morphism a \ A ^ A! for a signature 27 = (S', F) and alge- 
bras A and A! is given a family of functions (cts : )s^s such that 

. . .Un)) = (asi(ui),...,as„(u„)) for / : (si)i<*<„ ^ sq€ F. 

The category S-Alg has as objects; 27-algebras, and as morphisms: 27-algebra mor- 
phisms. The composition of 27-algebra morphisms is defined as function composition; 
the identity morphism on a 27-algebra is given by the family of identity functions on its 
universes. 

A signature morphism cr : 27 ^ 27' for signatures 27 = {S, F) and 27' = (S', F') 
induces a functor : E'-Alg — > E-Alg such that, for an A' G \S'-Alg\, = 

crfs)^' for s G S and = cr(f)^' for f G F', and (a' : A! — > B')\ = a : 

^ B'\„ where (a^j^es = 

The category Alg has as objects: the categories E-Alg for signatures 27, and as 
morphisms: for every signature morphism a : E ^ E' the reduct functor The com- 
position of Al^-morphisms is defined as functor composition; the identity morphism on 
the category E-Alg is given by the reduct functor from the identity signature morphism 
id : 27 ^ 27. 

B Viewpoints 

B.l Structural Viewpoint 

Syntax. A structure diagram (C, A) consists of a set of classes C and a set of associa- 
tions A. Each class 7 G C is given by its (unique) name; a set of attributes of the form 
a : T with a a (unique) name and r the name of a class in C; and a set of methods of the 
form m : (ri)i<i<fc — > tq (fc G N) with m a (unique) name and tq, n, . . . , rs, names of 
classes in C. Each association a G A is given by a pair of association ends of the form 
(fli : Ti, 02 : T 2 ) with oi, 02 (unique) names and n, T 2 names of classes in C. 

A structure diagram morphism a : {C, A) {C , A') is given by a map a from 
the names of (C, A) to the names of (C", A') such that a class name is mapped to a 
class name, an attribute name is mapped to an attribute name, &c; and the following 
conditions hold: (1) Given a class 7 G C with name n, attributes oi : ri, . . . , Ofc : Tk, 
and methods TOi : {Tu)i<^<ki rio,...,m; : m the class 7 ' G C" 

denoted by a{n) has at least the attributes cr(ai) : ct(ti), . . . ,cr{ak) '■ (^{Tk) and at 
least the methods (r(mi) : cr(rio), . . . , cr(mz) : (cr(rii))i<i<fe, ^ 

<t(t/o); (2) given an association (oi : ri,a 2 '■ T 2 ) G A there is an association {cr{ai) : 
<T(ri),cr(a2 ) : ct(t2 )) G A'. 

The category StructDiag has as objects: structure diagrams, and as morphisms: 
structure diagram morphisms. The composition of structure diagram morphisms is de- 
fined as function composition; the identity morphism on a structure diagram is given by 
the identity on the structure diagram’s names. 

Signature. The signature of a structure diagram Sig((C, A)) = (S,F) is defined as 
follows: (1) S' contains a distinguished sort State. (2) Every class name in C gives 
rise to a sort symbol in S. (3) An attribute a : r of a class with name 7 gives rise 
to an operation a : State x 7 ^ t in S’. (4) A method m : (ri)i<i<fc — *■ tq of 
a class with name 7 gives rise to operations m : State x 7 x (ri)i<i<fe ^ tq and 
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mstate : State x 7 x (ri)i<i<fc — > State in F. ( 5 ) An association (ai : n,a2 : T2) 
in A gives rise to the operations ai : State x T2 ^ n and 02 : State x n ^ T2 in F. 
(6) S and F are the least such sets under inclusion. 

As each structure diagram morphism naturally induces a signature morphism, 
the signature mapping on objects of StructDiag can be extended to a functor Sig : 
StructDiag — > Sig. 

Semantics. The semantics Mod((C, A)) of a structure diagram (C, A) is given by 
Sig((C', A))-Alg. The full sub-category of Alg induced by the image of Mod is called 
StructAlg. This semantics on objects of StructDiag is lifted to a functor Mod : 
StructDiag°'^ — > S'trMctAl^ by setting Mod(cr°P : {C',A') — > (C, A)) = tsig(o-) ■ 
Mod((C", A')) ^ Mod((C, A)). 

B.2 Behavioural Viewpoint 

Syntax. A behaviour specification (( 7 , pre, post) consists of a set of classes C and 
mappings pre and post from the methods of classes from C to pre- and postcondition 
specifications. Each class 7 G C is given by its (unique) name; a set of attributes of the 
form a : r with a a (unique) name and r the name of a class in C; and a set of methods 
of the form m : {xi : Ti)i<i<k — > tq (A: G N) with m a (unique) name, Xi, . . . ,Xn 
(unique) parameter names, and tq, ti, . . . , names of classes in C. A pre-condition of 
a method m of class 7 G C is given by a boolean term involving the names of attributes 
of 7 and the parameter names of m. A postcondition of a method m of class 7 G C is 
given by boolean term involving the names of attributes of 7, references to the pre-state 
of attributes using the special notation @pre, and the special constant result. 

A behaviour specification morphism [3 : (C, pre, post ( is given by a map (3 from 
the names of (C, pre, post) to the names of (C", pre', post') such that a class name 
is mapped to a class name, an attribute name is mapped to an attribute name, &c; 
and the following conditions hold: ( 1 ) Given a class 7 G C with name n, attributes 
fli : n,...,afc : r^, and methods mi : {xu : Tu)i<i<ki — > : {xu : 

— > T;o the class 7' G C" denoted by a{n) has at least the attributes cr(ai) : 
<T(riy, . . . , tj(afe) : cr(rfe) and at least the methods cr(mi) : (cr(a;ii) : cr(rii))i<i<fci ^ 
(r(rio), . . . ,(r(mi) : {a{xu '. a{Tu))i<i<ki ^ cr(rio). ( 2 ) The homomorphic images of 
the pre- and postconditions of a method m of class 7 w. r. t. /? is a pre- and postcondition 
of ( 3 {m), resp. 

The category BehSpec has as objects: behaviour specifications, and as morphisms: 
behaviour specification morphisms. The composition of behaviour specification mor- 
phisms is defined as function composition; the identity morphism on a behaviour spec- 
ification is given by the identity on the behaviour specification’s names. 

Signature. The signarMre of a behaviour specification Sig((C, pre, post)) = (S,F) is 
defined as follows: ( 1 ) S contains a distinguished sort State. ( 2 ) Every class name in 
C gives rise to a sort symbol in S. ( 3 ) An attribute a : r of a class with name 7 gives 
rise to an operation a : State x 7 — *■ r in f. ( 4 ) A method m : (ri)i<i<fc — *■ tq of 
a class with name 7 gives rise to operations m : State x 7 x (ri)i<i<fe ^ tq and 
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mstate : State x 7 x (ri)i<i<fc — > State in F. ( 5 ) S and F are the least such sets 
under inclusion. 

As each behaviour specification morphism naturally induces a signature morphism, 
the signature mapping on objects of BehSpec can be extended to a functor Sig : BehSpec 
Sig. 

Semantics. The semantics Mod((C, pre, post)) of a structure diagram (C, pre, post) 
is given by the full sub-category of Sig((C, pre, post))-AZ5-algebras A satisfying the 
following condition: The interpretation of a pre-condition of a method m : {xi : 
fi)i<i<k tq over an s G State"^ and parameters x\ = Vi, . . . ,Xk = Vk implies the 
interpretation of the postcondition of m over s and mstate^ (s, vi, . . . , Vn) with xi = 
vi, . . . ,Xk = Vk and result^ = m(s, vi, . . . ,Vn). The full sub-category of Alg induced 
by the image of Mod is called BehAlg. This semantics on objects of BehSpec is lifted 
to a functor Mod : BehSpec°^ — *■ BehAlg by setting Mod((r°P : (C", pre', post') ^ 
(C, pre, post)) = : Mod((C", pre', post')) ^ Mod((C', pre, post)). 

B.3 Instance Viewpoint 

Syntax. An object diagram {O, L) is given by a set of objects O and a set of links L. 
An object o G O is given by a (unique) name; a type (name); and a set of slots of the 
form a = V with a a (unique) name and v an object in O. Each link A G L is given 
by a pair of link ends of the form (oi = v\, 02 = V2) with 01,02 (unique) names and 
vi , V2 objects in O. An object diagram has to be well-typed: If o and o' both show type 
T then: (l)ifo = i;isa slot of o with v an object with type r there is a slot a = v' of 
o' with v' an object with type r; (2) if there is a link (oi =0,02 = W2) then there is 
a link (oi = o', 02 = ( 3 ) if there is a link (oi = ui, 02 = o) then there is a link 

(oi = uj,02 = o'). 

An object diagram morphism l : (O, L) — > (O', L') is given by a map t from O to 
O' such that the following conditions hold: ( 1 ) Given an object o G O with name n, 
type T, and slots a\ = v\, . . . ,ak = Vk, the object i(o) G O' has type r and at least the 
slots oi = i(t’i), . . . , i(afc) = o'(i'fc); (2) given a link (oi = Vi,a2 = V2} & L there is 
a link (ai = t{vi), «2 : t{v2)) G L'. 

The category ObjDiag has as objects: object diagrams, and as morphisms: object 
diagram morphisms. The composition of object diagram morphisms is dehned as func- 
tion composition; the identity morphism on an object diagram is given by the identity 
on the object diagram’s objects. 

Signature. The signature Sig(( 0 , L)) = {S, F) of an object diagram (O, L) is dehned 
as follows: ( 1 ) Every type name of an object in O gives rise to a sort symbol in S. 

( 2 ) Every object o in O with type r gives rise to a constant operation o : — > r in F. 

( 3 ) A slot a = u of an object with type r and v an object with type r' gives rise to an 
operation a : r — > r' in F. ( 4 ) A link (oi = vi, 02 = V2) in L with vi, V2 objects with 
types Ti, T2, resp., gives rise to the operations ai : T2 ^ ri, 02 : ti ^ T2 in F. ( 5 ) S 
and F are the least such sets under inclusion. 

As each object diagram morphism naturally induces a signature morphism, the sig- 
nature mapping on objects of ObjDiag can be extended to a functor Sig : ObjDiag 
Sig. 
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Semantics. The semantics Mod((0, L)) of an object diagram (O, L) is given by the full 
sub-category of Sig((0, L))-algebras A satisfying the following conditions: If a = v 
is a slot in {0,L) then a^{o^) = if {a\ = V\,a 2 = V 2 ) is a link in (0,L) then 
and = v^- The full sub-category of Alg induced by the image 

of Mod is called InstAlg. This semantics on objects of ObjDiag is lifted to a functor 
Mod : OhjDiag°'^ by setting Mod(cr°P : {0',L') (0,L)) = fstgiCT) ■ 

Mod((0',L')) ^Mod((0,L)). 

B.4 Interaction Viewpoint 

Syntax. An interaction diagram {0,M,<) is given by a set of objects O, a set of 
messages M, and a partial order < C M x M. Each object o € O is given by a 
(unique) name and a type (name). Each message m G M is given by a (unique) name; 
a sender object in O, a receiver object in O, and a message label name. 

An interaction diagram morphism p, : {O, M, <) — > (O', M', <') is given by a map 
p from the names of (O, M, <) to the names of (O', M', <') such that object names are 
mapped to object names, type names are mapped to type names, &c., and the following 
conditions hold: (1) A message m G M with sender s G O, receiver r G O, and label 
/ is mapped to message p{m) G M' with sender p{s) G O', receiver p{r) G O', and 
label p{l). (2) If m < n for messages m,n G M then p{m) <' p{n). 

The category InterDiag has as objects: interaction diagrams, and as morphisms: 
interaction diagram morphisms. The composition of interaction diagram morphisms is 
defined as function composition; the identity morphism on an interaction diagram is 
given by the identity on the interaction diagram’s messages. 

Signature. The signature Sig((0,M, <)) = {S,F) of an interaction diagram 
(O, M, <) is defined as follows: (1) S contains distinguished sorts Obj, Label, Msg, 
and Boolean. (2) Every type name r of an object in O gives rise to a sort symbol t in 
S. (3) F contains distinguished operation symbols sender : Msg — > Obj, receiver : 
Msg ^ Obj, label : Msg — > Label, and < : Msg x Msg ^ Boolean. (4) Every object 
o G O with type name r gives rise to a constant operation symbol o : ^ t. (5) Every 
message label I in M gives rise to a constant operation I : — > Label. (6) Every message 
with identifier m gives rise to a constant operation symbol m : Msg. (7) S and F 

are the least such sets under inclusion. 

As each interaction diagram morphism naturally induces a signature morphism, 
the signature mapping on objects of InterDiag can be extended to a functor Sig : 
InterDiag Sig. 

Semantics. The semantics Mod((0, M, <)) of an interaction diagram {0,M,<) is 
given by the full sub-category of Sig((0, M, <))-algebras A satisfying the following 
conditions: (1) The sort symbol Boolean is interpreted as the standard booleans, i.e. 
Boolean"^ = B. (2) Obj is interpreted as the union of the interpretion of all sort symbols 
T for object type names. (3) If m is a message in M with sender s, receiver r, and mes- 
sage label I, then sender"’^ (m^) = and receiver^(m^) = r^ and label"^(m^) = 
l^. (4) If m and n are messages in M with m < n then = true. The 
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full sub-category of Alg induced by the image of Mod is called Inter Alg. This seman- 
tics on objects of InterDiag is lifted to a functor Mod : InterDiag°^ InterAlg 
by setting Mod(tr°P : ^ {0,M,<}) = rsig(.) : Mod((0', M', <')) ^ 

Mod((0,M,<)). 



B.5 State Machine Viewpoint 

Syntax. A state machine diagram {C, fj) is given by a set of classes C and a mapping 
fj, of classes to machines. Each class 7 G C is given by its (unique) name; a set of 
attributes of the form a : r with a a (unique) name and r the name of a class in C\ and 
a set of methods of the form m : {Ti)i<i<k ^ tq (k G N) with m a (unique) name 
and To , Ti , . . . , Tfc names of classes in C. A machine of class 7 G C is given by a set S 
of (unique) state names, a set T of transitions, and an initial state i G S. A transition 
of a machine of class 7 is given by a source state si G 5, an incoming event e from 
the method names of C, a guard as a boolean expression of the names of attributes of 
7 and the names of parameters of the event e, an effect consisting of a statement over 
the names of attributes of 7 and the names of parameters of the event e and a subset of 
outgoing messages, and a target state S 2 G S. An outgoing message of a machine of 
class 7 is given by the name of an attribute of 7 and the name of a method name of the 
class of this attribute and list of expressions over the names of attributes of 7 and the 
parameters of e. 

A state machine diagram morphism (3 : —>■ {C ,p!) is given by a map (3 

from the names in (C, p) to the names in (C", p') such that class names are mapped 
to class names, attribute names are mapped to attribute names, &c., and the following 
condition holds: p' {(3{C)) = (3{p{C)) where f3{p{C)) is the homomorphic extension 
of f3 to guards, statements, and expressions. 

The category MachDiag has as objects: state machine diagrams, and as morphisms: 
state machine diagram morphisms. The composition of state machine diagram mor- 
phisms is defined as function composition; the identity morphism on a state machine 
diagram is given by the identity on the state machine diagram’s classes, attributes, and 
method names. 

Signature. The signature Sig{{C,p)) = (S,F) of a state machine diagram (C,p) is 
defined as follows: (1) S contains distinguished sorts Obj, Set(Obj), Env, State, Msg, 
and Set (Msg). (2) Every class name y G C gives rise to a sort symbol 7 in S. (3) F 
contains a distinguished operation symbol obj : Env — > Set(Obj). (4) F contains 
a distinguished operation symbol initial : — > State. (5) F contains distinguished 
operation symbols state : Obj x State x Env — > State, env : Obj x State x Env ^ 
Env, msg : Obj x State x Env ^ Msg. (6) An attribute a : r of a class with name 7 
gives rise to an operation a : Env x 7 ^ r. (7) A method (ri)i<i<fe ^ tq of a class 
with name 7 gives rise to an operation m : ^ x (ri)i<i<fc ^ Msg. (7) S and F are the 
least such sets under inclusion. 

As each state machine diagram morphism naturally induces a signature morphism, 
the signature mapping on objects of MachDiag can be extended to a functor Sig : 
MachDiag — > Sig. 
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Semantics. The semantics Mod{{C, fj.)) of a state machine diagram is given 

by the full sub-category of Sig((C', /i))-algebras A satisfying the following conditions: 
(1) The sort symbol Obj is interpreted as the union of the interpretions of the sort 
symbols r for classes. (2) The sort symbol Set (Obj) is interpreted as the standard sub- 
sets of the interpretion of Obj; the sort symbol Set (Msg) is interpreted as the standard 
subsets of the interpretion of Msg. (3) The operaton symbol env is interpreted as the 
function that given an object in the interpretion of sort r, a state si of the machine of 
class r, and an environment e yields the environment resulting from executing the ma- 
chine for class r in one step. The operation symbols state and msg are to be interpreted 
similarly, but resulting in the state and the outgoing messages, respectively. The full 
sub-category of Alg induced by the image of Mod is called MachAlg. This semantics 
on objects of MachDiag is lifted to a functor Mod : MachDiag°^ — > MachAlg by 

setting Mod(a°P : (C",^') ^ (C,^)) = (sigla) : Mod((C",M')) ^ Mod((C,M))- 
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